Qu’est-ce que la prévention des scripts inter-sites ?
La prévention des scripts inter-sites consiste à détecter et à corriger les vulnérabilités XSS de vos sites Web ou applications Web avant qu’elles ne soient en production. La détection des vulnérabilités XSS peut être effectuée automatiquement, à l’aide d’un scanner de vulnérabilités automatisé, ou manuellement en effectuant des tests de pénétration. Dans cet article, vous apprendrez les meilleures pratiques pour la prévention des scripts inter-sites et comment les implémenter immédiatement. À la fin de l’article, vous trouverez également un lien vers un scanner de vulnérabilités gratuit axé sur les développeurs afin que vous puissiez commencer à détecter et à corriger les vulnérabilités de script intersite tôt et souvent, dans le cadre de vos pipelines de développement
Dans cet article, vous apprendrez:
- Qu’est-ce que la Prévention des scripts Inter-Sites ?
- Comment fonctionne le script intersite ?
- Quels sont les types d’attaques XSS ?
- Quelle est l’importance de la prévention des scripts inter-sites ?
- Protection contre les scripts inter-sites
- Échapper au contenu dynamique
- Valeurs de liste blanche
- Mettre en œuvre une politique de sécurité du contenu
- Assainir HTML
- Cookies HTTP uniquement
- Prévention XSS avec exemples de code
- Prévention des scripts intersite en Python (Django)
- Prévention des scripts intersite en Ruby (Rails)
- Prévention des scripts intersite en Java (Pages de serveur Java)
- Prévention des scripts intersite en C# (ASP.NET)
- Prévention des scripts inter-sites dans le nœud
- Moustache.js
- Poussière.js
- Nunjucks
- Prévention des scripts intersite en PHP
- Prévention des scripts intersite dans AngularJS
- Prévention des scripts intersite dans React
- Comment les outils automatisés peuvent-ils aider à empêcher les scripts intersite ?
Comment fonctionne le script intersite ?
Les attaques XSS (Cross-Site Scripting) sont une forme d’attaque par injection, dans laquelle des scripts malveillants sont injectés dans des applications Web de confiance.
Un attaquant peut utiliser l’application Web pour envoyer du code malveillant, généralement sous la forme d’un script côté navigateur, à un utilisateur final différent, entraînant une attaque XSS.
Les vulnérabilités XSS sont très courantes lorsqu’une application Web utilise l’entrée d’un utilisateur valide contenue dans la sortie générée, mais sans la validation ou l’encodage appropriés.
Avec le script malveillant envoyé à l’utilisateur, son navigateur ne peut pas savoir catégoriquement que le script ne doit pas être approuvé et exécute ensuite le script. Ce script peut alors accéder à une multitude de données, notamment les éventuels cookies, jetons de session, ou encore toute autre information sensible pouvant être conservée par le navigateur de ce site.
Quels sont les types d’attaques XSS ?
Il existe trois principaux types d’attaques XSS:
- XSS reflété : le script malveillant provient de la requête HTTP actuelle
- XSS stocké: le script malveillant provient de la base de données XSS basée sur le DOM du site Web
- : où la vulnérabilité existe dans le code côté client plutôt que dans le code côté serveur.
Quelle est l’importance de la prévention des scripts inter-sites ?
Les dommages causés par l’exploitation d’une vulnérabilité XSS dépendent de la sensibilité des données traitées par votre site. Voici quelques exemples où des pirates informatiques ont exploité des applications vulnérables XSS:
- Propagation de vers sur les médias sociaux: Facebook, Twitter et YouTube ont tous été attaqués avec succès de cette manière.
- Détournement de session: JavaScript malveillant peut être en mesure d’envoyer l’ID de session à un site distant sous le contrôle du pirate, permettant au pirate de se faire passer pour cet utilisateur en détournant une session en cours.
- Vol d’identité: Si l’utilisateur entre des informations confidentielles telles que des numéros de carte de crédit dans un site Web compromis, ces informations peuvent être volées à l’aide de JavaScript malveillant.
- Attaques par déni de service et vandalisme de site Web.
- Vol de données sensibles, comme les mots de passe.
- Fraude financière sur les sites bancaires.
Protection de script intersite
Échapper au contenu dynamique
Habituellement, lorsqu’une page Web est rendue, le contenu dynamique est tissé en HTML. Si le contenu dynamique est mal traité, un attaquant peut l’utiliser pour construire une attaque XSS stockée. L’attaquant abuserait d’un champ modifiable en insérant du code JavaScript malveillant, qui est évalué dans le navigateur lorsqu’un autre utilisateur visite cette page.
Il se peut que vous ne souhaitiez pas que vos utilisateurs créent du HTML brut à moins que votre site ne soit un système de gestion de contenu. Échappez tout le contenu dynamique provenant d’un magasin de données, afin que le navigateur sache qu’il doit être traité comme le contenu de balises HTML, par opposition au HTML brut.
L’échappement du contenu dynamique consiste généralement à remplacer les caractères significatifs par l’encodage d’entité HTML:
» "
# #
& &
‘ '
( (
) )
/ /
; ;
< <
> >
Comme vous le verrez dans les exemples de code ci-dessous, la plupart des frameworks modernes échapperont au contenu dynamique par défaut.
En échappant ainsi le contenu modifiable, le contenu ne sera jamais traité comme du code exécutable par le navigateur. Cela empêchera la plupart des attaques XSS.
Valeurs de liste blanche
Si un élément de données dynamique ne peut prendre qu’une poignée de valeurs valides, limitez les valeurs dans le magasin de données. Assurez-vous également que votre logique de rendu n’autorise que des valeurs correctes connues.
Un exemple où vous pouvez utiliser cette approche consiste à demander à un utilisateur de sélectionner son pays dans une liste déroulante, au lieu de le saisir manuellement.
Implémentez une stratégie de sécurité du contenu
Les navigateurs modernes prennent en charge les stratégies de sécurité du contenu. Les stratégies de sécurité du contenu permettent à l’auteur d’une page Web de contrôler à partir de laquelle JavaScript et d’autres ressources peuvent être chargés et exécutés.
Pour qu’une attaque XSS soit possible, l’attaquant doit pouvoir exécuter des scripts malveillants sur la page Web d’un utilisateur – soit en injectant des balises <script > en ligne quelque part dans la balise <html > d’une page, soit en incitant le navigateur à charger le JavaScript à partir d’un domaine tiers malveillant.
La définition d’une stratégie de sécurité du contenu dans l’en-tête de réponse vous permettra d’indiquer au navigateur de ne jamais exécuter JavaScript en ligne et de choisir les domaines pouvant héberger JavaScript pour une page:
Content-Security-Policy: script-src 'self' https://apis.google.com
En mettant sur liste blanche les URL à partir desquelles les scripts peuvent être chargés, vous indiquez implicitement que JavaScript en ligne n’est pas autorisé.
Vous pouvez également placer la stratégie de sécurité du contenu dans une balise <meta> dans l’élément <head> d’une page:
<meta http-equiv="Content-Security-Policy" content="script-scr 'self' https://apis.google.com">
Cette approche est très efficace pour protéger vos utilisateurs, mais nécessite de la discipline pour préparer votre site à un tel en-tête. Bien qu’avoir des scripts en ligne soit considéré comme une mauvaise pratique dans le développement Web moderne, ils sont courants dans les anciens sites hérités.
Pour migrer progressivement des scripts en ligne, envisagez d’utiliser les rapports de violation CSP. En ajoutant une directive report-uri dans l’en-tête de votre stratégie, le navigateur vous avertira de toute violation de stratégie, plutôt que d’empêcher l’exécution de JavaScript en ligne:
Content-Security-Policy-Report-Only: script-src 'self'; report-uri http://example.com/csr-reports
Cela vous rassurera qu’il n’y a pas de scripts en ligne persistants, avant de les interdire purement et simplement.
Assainir le HTML
Pour certains sites, il existe un besoin légitime de stocker et de rendre du HTML brut. Si votre site stocke et rend du contenu riche, vous devez utiliser une bibliothèque de désinfection HTML pour vous assurer que les utilisateurs malveillants ne peuvent pas injecter de scripts dans leurs soumissions HTML.
Cookies HTTP uniquement
Du JavaScript malveillant peut être utilisé pour voler un cookie contenant l’identifiant de session de l’utilisateur. Il y a rarement une bonne raison de lire ou de manipuler les cookies en JavaScript côté client, alors pensez à marquer les cookies comme HTTP uniquement, ce qui signifie que les cookies seront reçus, stockés et envoyés par le navigateur, mais ne peuvent pas être modifiés ou lus par JavaScript.
Prévention XSS avec exemples de code
Prévention des scripts inter-sites en Python (Django)
Modèles dans Django escape HTML par défaut, donc tout ce qui ressemble à ce qui suit est généralement sûr:
**{{ contents }}**
Vous pouvez remplacer l’échappement en utilisant le filtre /safe. Il y a souvent de bonnes raisons de le faire, mais vous devrez effectuer des examens du code sur tout ce qui utilise cette commande:
**{{ contents | safe }}**
Notez que l’échappement HTML peut également être activé ou désactivé avec la balise {% autoescape %}.
Prévention des scripts inter-sites dans Ruby (Rails)
Les modèles Rails échappent au HTML par défaut, donc tout ce qui ressemble à ce qui suit est généralement sûr:
<%= contents %>
Vous pouvez remplacer l’échappement en utilisant la fonction raw ou en utilisant l’opérateur <%==. Il y a souvent de bonnes raisons de le faire, mais vous devrez effectuer des examens du code sur tout ce qui utilise ces fonctions:
<% raw contents %>
<%== contents %>
Prévention des scripts inter-sites en Java (Pages Serveur Java)
Utilisez la balise c:out pour échapper en toute sécurité au HTML:
<c:out value="${contents}">
Les méthodes d’écriture suivantes dans un modèle n’échappent pas au HTML, vous devez donc les utiliser avec précaution:
<%= contents %>
${contents}
<%
out.println(contents);
%>
Prévention des scripts inter-sites en C# (ASP.NET)
Utilisez l’une des fonctions suivantes pour échapper en toute sécurité au HTML (le formulaire <%: a été introduit dans ASP.NET 4.0):
<%= HttpUtility.HtmlEncode(contents) %>
<%: contents %>
La façon suivante d’écrire dans un modèle n’échappe pas automatiquement au HTML, vous devez donc les utiliser avec précaution:
<%= contents %>
Utilisez HttpUtility.HtmlEncode(...) si vous devez échapper manuellement HTML.
Prévention des scripts inter-sites dans le nœud
Moustache.js
En Moustache.js, toutes les balises dans les moustaches doubles échappent automatiquement au HTML:
{{ contents }}
Gardez à l’esprit que les balises des moustaches triples n’échappent pas au HTML, alors utilisez-les avec précaution:
{{{ contents }}}
Poussière.les balises js
échappent automatiquement au code HTML:
{ contents }
Cependant, l’échappement peut être désactivé avec l’opérateur |s, utilisez-le avec précaution
{ contents | s }
Nunjucks
Si l’échappement automatique est activé dans l’environnement, Nunjucks échappera automatiquement les balises pour une sortie sûre:
{{ contents }}
Le contenu marqué avec le filtre sûr ne sera pas échappé – utilisez cette fonction avec précaution:
{{ contents | safe }}
L’échappement automatique peut être désactivé pour un modèle, auquel cas les balises doivent être échappées manuellement:
{{ contents | escape }}
Prévention des scripts inter-sites en PHP
La commande echo en PHP n’échappe pas au HTML par défaut, ce qui signifie que tout code comme le suivant qui extrait directement les données de la requête HTTP est vulnérable aux attaques XSS:
<?php
Echo $_POST;
?>
Prévention des scripts inter-sites dans AngularJS
Tout contenu écrit entre crochets sera automatiquement échappé, ce qui suit est donc sûr:
<div>{{dynamicContent}}</div>
Gardez à l’esprit que tout code qui lie du contenu dynamique à l’attribut innerHTML ne sera pas automatiquement échappé:
<div ="dynamicContent"></div><div innerHTML]="{{dynamicContent}}"></div>
Prévention des scripts inter-sites dans React
Tout contenu dynamique écrit entre crochets sera automatiquement échappé dans React, de sorte que le code suivant est sûr:
render() {
return <div>{dynamicContent}</div>
}
Vous pouvez également écrire du HTML brut en liant le contenu à la propriété dangerouslySetInnerHTML. Le nom n’est pas une coïncidence, alors recherchez tout code qui ressemble à ce qui suit:
render() {
return <div dangerouslySetInnerHTML={ __html: dynamicContent } />
}
Comment les outils automatisés peuvent-ils aider à empêcher les scripts intersite ?
Comme mentionné ci-dessus, la prévention des attaques de script intersite peut être facile, de nombreux frameworks échappant au contenu dynamique par défaut. Mais cette commodité peut entraîner une inadvertance et de graves faiblesses de sécurité pour votre application et votre entreprise.
Assurez-vous toujours d’analyser les vulnérabilités de vos applications avant de les mettre en production, idéalement dans le cadre de vos pipelines DevOps et CI/CD pour détecter et corriger les vulnérabilités de sécurité rapidement, à chaque génération/validation.
Vous pouvez commencer à automatiser vos tests de sécurité dès aujourd’hui avec Nexploit, le scanner dynamique de tests de sécurité des applications de NeuraLegion. Conçu pour les développeurs et sans faux positifs, vous pouvez l’intégrer à vos pipelines pour déplacer les tests de sécurité vers la gauche et être sécurisé dès la conception.
Créez votre compte GRATUIT ici: https://nexploit.app/signup