Cross site scripting

Un article de Wikipédia, l'encyclopédie libre.

Cet article ou cette section ne cite pas suffisamment ses sources. (date inconnue)

Son contenu est donc sujet à caution. Wikipédia doit être fondée sur des sources fiables et indépendantes. Améliorez cet article en liant les informations à des sources, au moyen de notes de bas de page (voir les recommandations).

Le Cross site scripting, abrégé XSS, est un type de faille de sécurité des sites Web, que l'on trouve typiquement dans les applications Web qui peuvent être utilisées par un attaquant pour faire afficher des pages web contenant du code douteux. Il est abrégé XSS pour ne pas être confondu avec le CSS (feuilles de style), X étant une abréviation commune pour « cross » (croix) en anglais.

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. »

Le principe est d'injecter des données arbitraires dans un site web, par exemple en déposant un message dans un forum, mais aussi par des paramètres d'URL, etc. Si ces données arrivent telles quelles dans la page web transmise au navigateur (par les paramètres d'URL, un message posté, etc.) 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.

Pour vérifier la présence d'une faille XSS, il suffit de faire passer un script, par exemple :

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

qui provoquera l'affichage d'une boîte de dialogue.

[modifier] Les risques

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

Affichage d'un contenu non interne au site (publicité, faux article)
Redirection (parfois de manière transparente) de l'utilisateur.
Vol d'informations, par exemple sessions et cookies.
Actions sur le site faillible, à l'insu de la victime et sous son identité (envois de messages, suppression de données, etc.)
Plantage de la page (boucle infinie d'alertes par exemple), et souvent du navigateur.

Une faille de type XSS est à l'origine de la propagation des virus Samy ( (en) explication et source du ver) sur MySpace en 2005 ainsi que de Yamanner sur Yahoo!Mail en 2006.

[modifier] Types de failles XSS

Il y a trois types de failles XSS

[modifier] Premier type

Ce type de faille XSS, qui est dit « basé sur DOM » ou « local », est connu de longue date. Un article récent (DOM-Based cross-site scripting) définit bien ses caractéristiques. Dans ce cas de figure, le problème est dans le script d'une page côté client. Par exemple, si un fragment de JavaScript accède à un paramètre d'une requête d'URL, et utilise cette information pour écrire du HTML dans sa propre page, et que cette information n'est pas encodée sous forme d'entités HTML, alors il y a probablement un trou XSS, puis les données écrites seront réinterprétées par le navigateur comme du HTML contenant éventuellement un script ajouté.

En pratique la manière d'exploiter une telle faille sera similaire au type suivant, sauf dans une situation très importante. À cause de la manière dont Internet Explorer traite les scripts côté client dans des objets situés dans la « zone locale » (par exemple le disque dur local du client), une faille de ce type peut conduire à des vulnérabilités d'exécution à distance. Par exemple, si un attaquant héberge un site web « malicieux » contenant un lien vers une page vulnérable sur le système local du client, un script peut être injecté et tournera avec les droits du navigateur web de l'utilisateur sur ce système. Ceci contourne complètement le « bac à sable », pas seulement les restrictions inter-domaines qui sont normalement contournées par les XSS.

[modifier] Second type

Ce type de trou de sécurité, qu'on peut qualifier de « non permanent », est de loin le plus commun.

Il apparaît lorsque des données fournies par un client web sont utilisées telles quelles par les scripts du serveur pour produire une page de résultats. Si les données non vérifiées sont incluses dans la page de résultat sans encodage des entités HTML, elles pourront être utilisées pour injecter du code dans la page dynamique reçue par le navigateur client.

Un exemple classique dans les moteurs de recherche des sites : si l'on recherche une chaîne qui contient des caractères spéciaux HTML, souvent la chaîne recherchée sera affichée sur la page de résultat pour rappeler ce qui était cherché, ou dans une boîte de texte pour la réédition de cette chaîne. Si la chaîne affichée n'est pas encodée, il y a une faille XSS.

À première vue, ce n'est pas un problème grave parce que l'utilisateur peut seulement injecter du code dans ses propres pages. Cependant, avec un peu d'ingénierie sociale, un attaquant peut convaincre un utilisateur de suivre une URL piégée qui injecte du code dans la page de résultat, ce qui donne à l'attaquant tout contrôle sur le contenu de cette page. L'ingénierie sociale étant requise pour l'exploitation de ce type de faille (et du précédent), beaucoup de programmeurs ont considéré que ces trous n'étaient pas très importants. Cette erreur est souvent généralisée aux failles XSS en général.

[modifier] Troisième type

Ce type de vulnérabilité, aussi appelé faille permanente ou du second ordre permet des attaques puissantes. Elle se produit quand les données fournies par un utilisateur sont stockées sur un serveur (dans une base de données, des fichiers, ou autre), et ensuite réaffichées sans que les caractères spéciaux HTML aient été encodés.

Un exemple classique est celui des forums, où les utilisateurs peuvent poster des textes formatés avec des balises HTML. Ces failles sont plus importantes que celles d'autres types, parce qu'un attaquant peut se contenter d'injecter un script une seule fois et atteindre un grand nombre de victimes sans recourir à l'ingénierie sociale.

Il y a diverses méthodes d'injection, qui ne nécessitent pas forcément que l'attaquant utilise l'application web elle-même. Toutes les données reçues par l'application web (par email, journaux, etc.) qui peuvent être envoyées par un attaquant doivent être encodées avant leur présentation sur une page dynamique, faute de quoi une faille XSS existe.

[modifier] Éviter la faille

Plusieurs techniques permettent d'éviter le XSS

Retraiter systématiquement le HTML de sortie via le CMS
Filtrer les variables affichées ou enregistrées avec des caractères '<' et '>' (en cgi comme en PHP)
Utiliser de façon propre les balises HTML <noscript></noscript>

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