Cross-site scripting

Le terme cross-site scripting n'est pas une description très précise de ce type de vulnérabilité. Mark Slemko, pionnier du XSS, en disait :

« Le problème n'est pas simplement le "scripting", et il n'y a pas forcément quelque chose entre plusieurs sites. Alors pourquoi ce nom ? En fait, le nom a été donné quand le problème était moins bien compris, et c'est resté. Croyez-moi, nous avions des choses plus importantes à faire que de réfléchir à un meilleur nom. »

— Mark Slemko, « Cross Site Scripting Info », sur The Apache HTTP Server Project, février 2000

Le principe est d'injecter des données arbitraires dans un site web, par exemple en déposant un message dans un forum, ou par des paramètres d'URL. Si ces données arrivent telles quelles dans la page web transmise au navigateur (par les paramètres d'URL, un message posté…) sans avoir été vérifiées, alors il existe une faille : on peut s'en servir pour faire exécuter du code malveillant en langage de script (du JavaScript le plus souvent) par le navigateur web qui consulte cette page.

La détection de la présence d'une faille XSS peut se faire par exemple en entrant un script Javascript dans un champ de formulaire ou dans une URL :

<script>alert('bonjour')</script>​

Si une boîte de dialogue apparaît, on peut en conclure que l'application Web est sensible aux attaques de type XSS.

L'exploitation d'une faille de type XSS permettrait à un intrus de réaliser les opérations suivantes :

• Redirection (parfois de manière transparente) de l'utilisateur (souvent dans un but d'hameçonnage)
• Vol d'informations, par exemple sessions et cookies.
• Actions sur le site faillible, à l'insu de la victime et sous son identité (envoi de messages, suppression de données…)
• Rendre la lecture d'une page difficile (boucle infinie d'alertes par exemple).

Il n'existe pas de classification standardisée des failles de cross-site scripting, mais l'on peut facilement distinguer deux types principaux de XSS : les non-persistants et les persistants. Il est aussi possible de diviser ces deux types en deux groupes : les XSS traditionnels (causés par une vulnérabilité côté serveur) et les XSS basés sur le DOM (dus à une vulnérabilité côté client)

Plusieurs techniques permettent d'éviter le XSS :

• Retraiter systématiquement le code HTML produit par l'application avant l'envoi au navigateur ;
• Filtrer les variables affichées ou enregistrées avec des caractères '<' et '>' (en CGI comme en PHP). De façon plus générale, donner des noms préfixés (avec par exemple le préfixe "us" pour user string) aux variables contenant des chaines venant de l'extérieur pour les distinguer des autres, et ne jamais utiliser aucune des valeurs correspondantes dans une chaîne exécutable (en particulier une chaîne SQL, qui peut aussi être ciblée par une injection SQL d'autant plus dangereuse) sans filtrage préalable.
• En PHP :
  • utiliser la fonction htmlspecialchars()​ qui filtre les '<' et '>' (cf. ci-dessus) ;
  • utiliser la fonction htmlentities()​ qui est identique à htmlspecialchars()​ sauf qu'elle filtre tous les caractères équivalents au codage HTML ou JavaScript.
• En ColdFusion :
  • utiliser la fonction HTMLEditFormat() qui remplace tous les caractères spéciaux du langage HTML par leur référence d'entité
  • définir l'attribut scriptProtect du tag <cfapplication> pour protéger automatiquement toutes les variables (form et/ou url et/ou cgi et/ou cookies) d'un site
  • activer au niveau du serveur une protection globale (form, url, cgi et cookies) par défaut de toutes les applications en cochant la case "Enable Global Script Protection" du ColdFusion Administrator

Il existe des bibliothèques qui permettent de filtrer efficacement du contenu balisé issu de l'utilisateur (systèmes de publication).

Par ailleurs, il est également possible de se protéger des failles de type XSS à l'aide d'équipements réseaux dédiés tels que les pare-feux applicatifs. Ces derniers permettent de filtrer l'ensemble des flux HTTP afin de détecter les requêtes suspectes.

Plusieurs attaques importantes ont utilisé des failles de type cross-site scripting :

• Une faille de ce type était à l'origine de la propagation des virus Samy sur MySpace en 2005[3] et Yamanner sur Yahoo! Mail en 2006.
• En 2010, le site apache.org a été compromis à l'aide d'une XSS[4].
• En septembre 2014, un informaticien écossais prévient le service technique du site d'enchère eBay de la présence d'une fausse annonce visant à soutirer des informations bancaires. Cette attaque exploitait une faille XSS[5].
• Le 23 août 2015 à partir de deux heures du matin et jusque vers midi, une faille XSS est utilisée sur les forums jeuxvideo.com pour remplacer certains contenus par des images[6].

• Pierre Gardenat, « XSS, de la brise à l'ouragan », sur Actes de la Conférence SSTIC 2009 (consulté le 26 juin 2009)
• (en) « XSS (Cross Site Scripting) Prevention Cheat Sheet », sur OWASP (consulté le 30 août 2012)