Accueil🇫🇷Chercher

Cross-site scripting

Le cross-site scripting (abrégé XSS) est un type de faille de sécurité des sites web permettant d'injecter du contenu dans une page, provoquant ainsi des actions sur les navigateurs web visitant la page. Les possibilités des XSS sont très larges puisque l'attaquant peut utiliser tous les langages pris en charge par le navigateur (JavaScript, Java...) et de nouvelles possibilités sont régulièrement découvertes notamment avec l'arrivée de nouvelles technologies comme HTML5. Il est par exemple possible de rediriger vers un autre site pour de l'hameçonnage ou encore de voler la session en récupérant les cookies.

Le diagramme de séquence d'une attaque de type cross-site scripting.

Le cross-site scripting est abrégé XSS pour ne pas être confondu avec le CSS (feuilles de style)[1], X se lisant « cross » (croix, à travers) en anglais.

DĂ©finition

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,

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.

Risques

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

Types de failles XSS

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)

XSS réfléchi (ou non permanent)

Ce type de faille de sécurité, qui peut être qualifié 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.

XSS stocké (ou permanent)

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…) 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.

Basé sur le DOM ou local

Ce type de faille XSS est connu de longue date. Un article écrit en 2005[2] 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 une vulnérabilité de type XSS. Les données écrites seront réinterprétées par le navigateur comme du code HTML contenant éventuellement un script malveillant 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 « malveillant » 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.

Protection contre les XSS

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.

Utilisation de XSS dans des attaques

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

Références

  1. (en) Steven Champeon, « XSS, Trust, and Barney (Reprinted from Webmonkey) », sur hesketh.com, (consulté le )
  2. (en) DOM-Based cross-site scripting
  3. (en) http://namb.la/popular/tech.html : explication et source du ver
  4. (en)Apache Infrastructure Team, « apache.org incident report for 04/09/2010 », sur The Apache Software Foundation, (consulté le )
  5. « De fausses annonces eBay piègent les utilisateurs », sur 01net.com, (consulté le )
  6. Jeuxvideo.com cible d’une tentative de piratage, lemonde.fr, 23 aout 2015

Voir aussi

Articles connexes

Liens externes

  • Owasp XSS, page traitant des vulnĂ©rabilitĂ©s
  • Xssed.com, site de rĂ©fĂ©rencement des failles XSS
Cet article est issu de wikipedia. Text licence: CC BY-SA 4.0, Des conditions supplémentaires peuvent s’appliquer aux fichiers multimédias.