Rappel : L’article qui va suivre contient des techniques et méthodes qui peuvent s’avérer être illégales et dangereuses si elles sont utilisées à mauvais escient. Ce tutoriel ne doit en aucun cas être utilisé contre un particulier, une entreprise, une organisation à but non lucratif ou une administration publique de quelconque pays. Je me dédouane de toute responsabilité en cas de problèmes ou d’incidents de quelque nature que ce soit après le visionnage de cet article.
Bonjour à tous ! Après avoir abordé les injections SQL il y a quelques semaines, aujourd’hui nous allons parler du sujet suivant : Les failles XSS. Je pense que ce nom doit peut-être vous évoquer quelque chose en fonction de votre domaine d’activité.
Les attaques de type Cross-Site Scripting (XSS, car le sigle CSS était déjà pris…) sont un type d’injection web, dans lequel des scripts malveillants (le plus souvent écrit en Javascript) sont injectés dans des formulaires, URL d’un site web. Elles sont assez répandues (surtout sur des site web hardcodé, sans CMS/Framwork Web) et peuvent être présentes lorsqu’une app web ne filtre pas (ou utilise un mauvais filtrage) les données transmises par un utilisateur.
Analogie : « If you give the keys of your car to somebody with permission to drive it to the store….they could also drive it anywhere ».
I. Que peut on faire avec une faille XSS ?
Les conséquences d’une attaque XSS peuvent être gravissime :
- Induire une fuite de données (Vol d’identifiant comme un cookie de session etc. afin de d’usurper une session utilisateur)
- Installer un malware si le hacker profite d’une vulnérabilité du navigateur utilisée par l’utilisateur victime.
- Impacter l’image de marque d’une entreprise. (Ex : l’incrustation de photo(s), message compromettant via une XSS stockée)
- Provoquer une attaque sous-jacente CSRF
- etc.
Durant cet article je vais utiliser l’application vulnérable DVWA pour les deux premières catégories de faille XSS.
II. Les types de failles XSS
Les attaques XSS peuvent être classées en 3 catégories :
- Stockée (aussi appelée persistante) ; En anglais : Stored XSS
- Reflétée (aussi appelée non-persistante) ; En anglais : Reflected XSS
- Basée sur le DOM ; En anglais : DOM-Based XSS
- Les attaques XSS reflétées (Reflected XSS)
Pourquoi les nomme-t-on non-persistantes ?
Tout simplement parce qu’elles dépendent d’une donnée entrée par l’utilisateur et parce qu’elles ne sont pas « stockées » (lorsque l’on poste un message sur un forum, celui-ci est stocké dans une bdd et réaffiché lorsqu’une autre personne visite la page).
Une autre personne visitant la même page quelques secondes après notre injection n’aurait absolument pas eu le même résultat, car elle cliquerait sur un lien différent. Cette attaque peut impacter un ensemble d’utilisateurs seulement s’ils cliquent tous sur le même lien corrompu, et qu’ils ont accès directement au même ressources sur le même site (Connexion requise ?). Afin d’atteindre le maximum de personne, il faudrait alors mettre en place une campagne de phishing, et espérer que les utilisateurs victimes cliquent sur le lien malicieux. Autrement dit, cela complexifie le processus d’attaque et sa portée.
Ci-dessous, j’injecte du code js : <script>alert("reflected xss")</script>, dans un formulaire. Dès lors que je clique sur submit, ce bout de code est injecté dans un lien URL puisque la méthode de transmission des données utilisée est GET.
Exemple de lien URL malicieux affichant une fenêtre d’alerte en javascript :
http://localhost/vulnerabilities/xss_r/?name=<script>alert("reflected xss")</script>
Schéma :
A. Les attaques XSS stockées (Stored XSS)
Cette variante d’attaque permet à un attaquant de pouvoir stocker du contenu malicieux (un script .js le plus souvent). Le code injecté est stocké. Reprenons l’exemple de notre forum.
Si vous postez le message « Salut « , chaque personne visitant la page en question verra « Salut » Maintenant imaginons qu’au lieu de « Salut » vous postiez : <h1> salut </h1> chaque personne visitant la page verra Salut ! en tant que titre et ce sans avoir à faire quoi que se soit. Vous voyez où je veux en venir ? 😉
Si vous postez <script>alert("hello world")</script>, chaque personne qui visitera la page aura une fenêtre d’alerte indiquant Salut ! Dans ce cas présent ce bout de code est trivial, mais imaginez si au lieu de <script>alert("hello world")</script> , un code JS malicieux est injecté permettant de récupérer des informations comme un cookie de session, ou bien étant capable d’impacter une faille de votre navigateur etc. vous imaginez les conséquences ?
En terme d’impact, les Stored XSS ont une portée plus importante que les Reflected XSS, car « vous ne cliquez pas délibérément sur un lien corrompu », lorsque vous accéder à un sujet de discussion d’un forum. En fonction de la portée de la faille, cette Stored XSS pourra impacter tous les utilisateurs (connectés ou non, en fonction du contexte) visitant la page infectée.
Schéma :
B. Les attaques XSS basées sur DOM (DOM XSS)
Le XSS basé sur DOM se produit lorsqu’un payload n’est jamais envoyé au serveur, c’est-à-dire que l’intégralité du flux de données malveillant profite d’une faille du code « Rendu (Comprendre affiché) » côté client. Cette variante est similaire au XSS reflété, mais la différence est qu’en modifiant le DOM, les données peuvent ne jamais parvenir au serveur.
Dans ce scénario, l’insertion de bout de code malicieux permet de passer « Sous les radars » des dispositifs WAF (Web Application Firewall) étant donné qu’aucun flux transite côté serveur web. J’insiste ! vu que le processus se déroule exclusivement côté client, la journalisation du serveur WEB, sera aveugle, et aucune trace ne sera laissée dans les logs du serveur web.
L’objectif principal de cette variante d’attaque est de dérober des informations comme des cookies (de session etc.), d’un utilisateur afin d’en usurper son identité. (et d’envisager potentiellement une attaque pivot.)
Ce type d’XSS est compliqué à mettre en oeuvre dans un contexte réel selon moi. Les XSS les plus rependues restes les deux premières. À noter que la faille XSS Stored, est plus virale qu’une faille XSS Reflected compte tenu du fait qu’elle est stockée de manière permanente dans une base de données. Celle-ci peut donc toucher un groupe d’utilisateur s’aventurant sur un forum par exemple…
III. Cas pratique
Dans ces trois vidéos, j’utilise l’application web vulnérable DVWA (Low security mode), le but étant que vous compreniez les fondamentaux de ces 3 attaques. Je vous montre en pratique comment réaliser le vol des cookies (cookie de session etc.) afin d’usurper le compte utilisateur ciblé. (Les trois premières vidéos sont de moi, tandis que la dernière est du Youtubeur : intigriti, qui approfondie le sujet concernant les Dom based XSS.
- Reflected XSS : https://www.youtube.com/watch?v=ErUhIbn0Lvg&ab_channel=Archidote
- Stored XSS : https://www.youtube.com/watch?v=mSWH2DBeHls&ab_channel=Archidote
- DOM XSS Based :
IV. Contres-mesures
A. Côté dev
Afin d’éviter ce type d’injection, qui peut s’avérer critique dans certain cas, il est impératif d’adopter des bonnes pratiques de filtrage des données lorsqu’un utilisateur est amené à saisir une quelconque donnée. Des fonction de filtrage notamment en PHP, ou bien en Node JS peuvent vous permettre d’appliquer certaines règles lors du traitement du flux de données transmis.
- PHP : Utiliser la fonction suivante
htmlspecialchars()qui est la fonction de prédilection pour « sanitizer* » les entrées de vos utilisateurs. Cette méthode est recommandée par l’organisme indépendant W3School, et est massivement utilisé depuis des années. - NODEJS : Je vous laisse consulter l’article suivant : https://www.section.io/engineering-education/how-to-prevent-cross-site-scripting-in-node-js/
- Javascript : https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html
Adopter des bonnes pratiques de programmation, vérifier le type de chaque données transmises et maintenir son code à jour, vous permettrons de limiter ce genre de faille.
*Sanitizer: Littéralement en français : « Filtre de nettoyage », ce mot décris la manière dont les données doivent être « nettoyer, purger avant transmission », afin d’éliminer des caractères spéciaux comme <, >, & /, etc, qui peuvent amener à rendre vulnérable une application. exemple : <h1>hello</h1>, après une action de sanitizing, il resterait simplement le mot hello .
Pour plus d’informations, consultez les liens suivants :
B. Côté Utilisateur lambda
Une attaque XSS peut venir de n’importe où et à tout moment, depuis un mail, un SMS etc. contenant un lien contaminé, ou bien lorsque vous naviguez sur internet. Vous pouvez utiliser un outil de protection de navigateur comme Paladin Browser Protection par exemple, en plus d’appliquer « les best practices » en matière de cybersécurité, qui selon moi sont les meilleurs remparts face à une quelconque attaque.
++
Merci @isster pour ta relecture.
Geoffrey
