XSS
Une injection de code indirecte (Cross Site Scripting, XSS) est une activité malveillante qui consiste à injecter des données arbitraires dans le code de pages HTML. Un utilisateur malveillant peut faire afficher à un site web vulnérable un contenu agressif ; ce contenu peut rediriger l’utilisateur vers d’autres sites, ou transmettre des informations (jetons de sessions, aussi appelés cookies, etc.) ou des droits.
Les données arbitraires sont souvent écrites en JavaScript, en HTML ou en vbscript. La personne malveillante introduit ainsi du code dans le serveur vulnérable qui héberge le site.
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) :
Attaques XSS stockées (XSS persistant)
Un XSS stocké ou persistant est considéré comme l’attaque de cross-site scripting la plus dévastatrice. Elle se produit quand une page Web va stocker puis afficher un contenu envoyé par un pirate.
Les points d’entrée pour les XSS stockés sont généralement des messages sur les forums, des commentaires sur des blogs, des profils utilisateurs et des champs de nom d’utilisateur. Un attaquant exploite généralement cette vulnérabilité en envoyant des charges utiles XSS sur des pages populaires ou en passant un lien à une victime, qui la redirigera vers une page contenant la charge utile XSS stockée. La victime visite la page et la charge utile est exécutée côté client par le navigateur Web de la victime.
Attaques XSS réfléchi (XSS 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.
À 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.
Attaques XSS basées sur le DOM
Le XSS basé sur le DOM fait référence à une faille de cross-site scripting qui apparaît dans le DOM (Document Object Model) au lieu d’être dans une partie de l’HTML. Dans les attaques XSS reflétées et stockées, on peut voir la charge utile de la vulnérabilité dans la page de réponse, mais dans les attaques basées sur le DOM, le code source HTML et la réponse seront les mêmes. En somme, la charge utile ne se trouvera pas dans la réponse. Elle ne pourra être observée qu’au moment de l’exécution ou en examinant le DOM de la page.
Ce type d’attaque se produit généralement côté client et la charge utile malveillante n’est jamais envoyée au serveur. Cela rend la détection encore plus difficile pour les pare-feu d’applications Web (WAF) et les ingénieurs en sécurité qui analysent les journaux des serveurs, car ils ne voient jamais l’attaque. Les objets du DOM qui sont le plus souvent manipulés sont l’URL (document.URL), la partie d’ancrage de l’URL (location.hash) et le référent (document.referrer).
