Cross-Site Scripting (XSS)

Le cross-site scripting – appelé XSS – est une vulnérabilité d’application qui a le potentiel de faire des ravages sur les applications et les sites Web. Le XSS est si répandu et potentiellement nuisible qu’il continue de figurer dans la liste des 10 principales vulnérabilités de l’Open Web Application Security Project (OWASP).

En fait, le Cross-Site Scripting est la vulnérabilité la plus courante découverte depuis 2014 et en 2019, elle continue d’apparaître dans le Top 3 des vulnérabilités signalées.

Dans certains cas, le script côté navigateur peut également introduire cette vulnérabilité permettant à un attaquant de l’exploiter sans que l’utilisateur cible fasse une requête à l’application web.

Les attaquants exploitent XSS en élaborant un code malveillant qui peut être acheminé vers un autre utilisateur, est ensuite exécuté par le navigateur non méfiant. Comme le script est le plus souvent inclus dans le contenu de la réponse de l’application web, il est exécuté et dispose des mêmes accès que si le script était légitime. L’accès peut être autorisé aux jetons de session, aux cookies et même aux informations confidentielles ou sensibles auxquelles le navigateur a accès sur ce site, voire même réécrire le contenu de la page HTML.

Attaque XSS réfléchie

Dans les attaques XSS réfléchies, le script malveillant est injecté dans une requête HTTP (généralement par un lien spécifiquement conçu fourni à l’utilisateur). Comme la variété la plus simple, elle utilise des paramètres d’entrée dans la requête HTTP qui peuvent être facilement manipulés pour inclure le contenu du script nuisible. Le script malveillant est ensuite réfléchi par le serveur dans une réponse HTTP et s’exécute dans le navigateur de la victime.

Dans ce cas, il agit comme un XSS stocké sans réellement stocker les données malveillantes sur le serveur.

Voici un exemple d’attaque XSS réfléchie :

Disons que exemple.com/profil contient un paramètre de nom. L’URL de la requête ressemblerait à ceci : https://example.com/profile?user=Tammy. Sur la base de cette entrée, l’application web répondrait donc par « Salut Tammy » en haut de la page. Si les paramètres ne sont pas validés pour s’assurer qu’ils ne contiennent que des données attendues, un attaquant pourrait faire en sorte qu’un utilisateur visite une version malveillante de l’URL comme celle-ci : https://example.com/profile?user<script>some_malicious_code</script&gt ;.

Lorsque la réponse est envoyée au navigateur, elle inclut ce script malveillant, qui est ensuite exécuté dans le navigateur, probablement à l’insu de l’utilisateur. C’est un exemple d’attaque XSS réfléchie, car le code malveillant est immédiatement « réfléchi » vers l’utilisateur qui fait la requête.

Attaques XSS stockées

Dans ce qu’on appelle une attaque XSS stockée ou persistante, le contenu malveillant est livré directement, avec la réponse du serveur lorsque l’utilisateur charge une page web. Le contenu est donc déjà stocké dans la base de données du site web (d’où le nom de ces attaques). Les utilisateurs n’ont alors qu’à entrer dans la page Web piratée et sont victimes de telles attaques.

Chaque utilisateur qui ouvre un tel site Web compromis risque donc de se faire voler ses données personnelles, et cela pourrait donc être considéré comme le type d’attaque XSS le plus dangereux.

Mais comment le contenu malveillant entre-t-il dans la base de données pour commencer ? Dans la plupart des cas, il est introduit par des formulaires de pages Web non protégés dans lesquels les entrées de l’utilisateur ne sont pas correctement validées et assainies. Si les données saisies par un pirate ne sont pas validées à la fois du côté client et du côté serveur, elles seront enregistrées dans la base de données. Par exemple, une telle entrée peut inclure une zone de texte de commentaire, un éditeur de texte de message, un éditeur de données personnelles, ou d’autres formulaires.

Une fois qu’un attaquant parvient à envoyer du contenu malveillant au serveur et que ce contenu apparaît non filtré sur une page web, tous les utilisateurs deviennent des victimes potentielles.Le remède commun pour les attaques XSS stockées est de sanitiser l’entrée à la fois sur le front-end et le back-end de l’application. L’aseptisation implique une combinaison de validation des données et d’échappement des caractères spéciaux ou de filtrage complet de ceux-ci et constitue une meilleure pratique courante pour la sécurité du Web et de JavaScript.

Attaques XSS basées sur le DOM

Le DOM (Document Object Model) est une interface qui permet aux applications de lire et de manipuler la structure d’une page Web, son contenu et son style. Dans une attaque XSS basée sur le DOM, la vulnérabilité se trouve dans le code script côté navigateur et peut être exploitée sans aucune interaction avec le serveur, en modifiant l’environnement du navigateur de la victime sans méfiance.

Parfois, les attaques XSS basées sur le DOM sont similaires aux attaques réfléchies. L’exemple ci-dessus d’une attaque XSS réfléchie peut être appliqué dans ce cas avec une seule hypothèse : L’application web lit les données directement à partir d’une chaîne de requête.

Disons que l’application utilise le paramètre de requête « name » afin d’afficher instantanément le nom de l’utilisateur à l’écran en attendant que le reste de la page se charge. Sans validation appropriée, cela peut donner le même résultat qu’avec une attaque réfléchie, si le pirate réussit à faire ouvrir à la victime un lien suspect.

Comme pour le XSS stocké, pour prévenir les attaques réfléchies et basées sur le DOM, les développeurs devraient mettre en œuvre la validation des données et éviter d’afficher l’entrée brute de l’utilisateur, malgré la présence ou l’absence de communication avec le serveur.

Quels sont les vecteurs d’attaque Cross-site Scripting?

Il existe plusieurs vecteurs couramment utilisés dans les attaques XSS :

• <balise de script> : Une balise script peut être utilisée pour référencer du code JavaScript externe, ce qui en fait le point XSS le plus simple. Les attaquants peuvent également intégrer le code malveillant dans la balise script.
• Événements JavaScript : Un autre vecteur XSS populaire utilisé par les attaquants, les attributs d’événements, peuvent être appliqués dans une variété de balises. Des attributs tels que « onerror » et « onload » en sont des exemples.
• <body> balise : Les attributs d’événements peuvent également être la source du script lorsqu’ils sont fournis par la balise « body ».
• <img> balise : Selon le navigateur utilisé, cet attribut peut être utile aux attaquants pour exécuter le code JavaScript.
• <iframe> balise : Particulièrement efficace pour les attaques de phishing, ce vecteur permet à l’attaque XSS d’intégrer une autre page HTML dans la page actuelle.
• <input> balise : Certains navigateurs permettent la manipulation par ce vecteur, qui peut être utilisé pour intégrer un script.
• <link> balise : Cette balise peut contenir un script, au lieu de l’utilisation normale de liens vers des feuilles de style externes.
• <table> balise : Là où l’attribut background fait normalement référence à une image, cela pourrait être compromis pour faire référence au script incriminé.
• <div> balise : Cette balise contient également une référence d’arrière-plan et peut être utilisée de la même manière que <table> pour faire référence à un script.
• <objet> balise : Les scripts d’un site externe peuvent être inclus à l’aide de cette balise.

Bien qu’il existe d’autres vecteurs que les attaquants XSS utilisent dans leurs efforts pour voler des informations et compromettre des sites Web, il s’agit de certaines des méthodes les plus couramment utilisées. Les développeurs doivent adhérer aux bonnes pratiques d’échappement et d’assainissement pour se prémunir contre ces attaques.

Dépendant de l’attaquant et de son intention malveillante, les attaques XSS peuvent entraîner différents impacts, notamment :

• le détournement de la session d’un utilisateur, l’utilisation d’informations d’identification pour accéder à d’autres sites ou rediriger l’utilisateur vers des sites web non souhaités,
• la modification de pages web ou l’insertion de sections dans une page web,
• l’exécution de scripts pour extraire des informations sensibles de cookies ou de bases de données,
• si la victime dispose de droits d’administration, l’attaque pourrait s’étendre au côté serveur, causant d’autres dommages ou récupérant des informations sensibles supplémentaires.

Les étapes clés du test des vulnérabilités XSS pour les applications web critiques comprennent :

• l’utilisation d’un outil de balayage de code pour détecter les vulnérabilités qui permettent de corriger le code pendant le processus de développement,
• la mise en œuvre d’une fonctionnalité de test automatisée qui révélera les vulnérabilités potentielles de manière approfondie et rapide.

Disons que exmple.com/profil contient un paramètre de nom. L’URL de la requête ressemblerait à https://example.com/profile?user=Tammy. L’application web répond avec « Hi Tammy » en haut de la page en fonction de cette entrée.

Si le paramètre utilisateur n’est pas validé pour s’assurer qu’il ne contient que des données attendues, un attaquant pourrait faire en sorte qu’un utilisateur visite une version malveillante de l’URL qui ressemble à ceci:
https://example.com/profile?user<script>some_malicious_code</script&gt ;.
Lorsque la réponse est envoyée au navigateur, elle inclut ce script malveillant qui est ensuite exécuté dans le navigateur, probablement à l’insu de l’utilisateur. Il s’agit d’un exemple d’attaque XSS réfléchie. Le code malveillant est immédiatement « reflété » vers l’utilisateur qui fait la demande.

• Éducation et sensibilisation : Assurez-vous que tous les développeurs, les concepteurs de sites Web et les équipes d’assurance qualité connaissent les méthodes utilisées par les pirates pour exploiter les vulnérabilités et fournissez des lignes directrices et les meilleures pratiques de codage. Cela inclut des techniques d’échappement/de codage appropriées pour l’environnement de l’application (JavaScript, HTML, etc.).
• Assainir les entrées : Que ce soit pour des pages web internes ou des sites web publics, ne faites jamais confiance à la validité des données saisies par l’utilisateur. Passez au crible et validez tous les champs de données, surtout s’ils seront inclus dans la sortie HTML.
• Analyser le code : Mettez en œuvre un logiciel qui scanne le code pour détecter les vulnérabilités, y compris le cross-site scripting, afin de garantir que les meilleures pratiques sont suivies et de minimiser l’exposition aux XSS et autres vulnérabilités répertoriées par l’OWASP.
• Politique de sécurité du contenu : Utilisez la politique de sécurité du contenu (CSP) pour définir ce qu’un site Web peut faire, et par là réduire le risque d’une attaque XSS. En utilisant la CSP, le XSS peut être bloqué entièrement (en bloquant tous les scripts en ligne) ou être réduit à un risque beaucoup plus faible.

L’OWASP fournit des conseils supplémentaires sur la façon de prévenir la vulnérabilité XSS avec une antisèche complète.