Ce troisième article de notre série dédiée à la compréhension des vulnérabilités web en 5 min nous présente les failles Cross Site Scripting (également connues sous le doux nom de XSS).
Les failles XSS sont très répandues sur Internet, et utilisées dans de nombreuses attaques aujourd’hui. Même si ces vulnérabilités sont pointées du doigt pas les experts en sécurité depuis des années, elles sont toujours très présentes dans nos applications. Les raisons sont a) Il est très facile de développer du code vulnérable à cette attaque et b) Ces failles sont assez pénibles à corriger.
L’impact de ces failles est assez important lorsqu’elles sont exploitées. Elle peuvent donner par exemple lieu à du vol de session (reportez-vous à l’article précédent de cette série pour plus de détails), un site défiguré, du code hostile injecté dans vos pages, un malware…

Pour faire simple, il existe 3 sous-types d’attaques XSS: attaques XSS stockées (stored XSS attacks), attaques XSS reflétées (reflected XSS attacks), attaques XSS basées sur le DOM (DOM based XSS).
Nous allons tenter d’expliquer ces trois types de failles avec des termes simples.

Ces trois types d’attaques utilisent des “contenus malicieux”. Par malicieux, comprenez un contenu qui sera affiché sur la navigateur de la victime, d’une manière non attendue.
Un exemple très simple est l’affichage d’une popup avec un message que la victime verra sur son navigateur, ou encore une redirection vers un site externe (généralement dangereux).
Nous ne détaillerons pas les possibles conséquences des attaques XSS, la liste est infinie, et elles sont parfois difficile à expliquer. Mais vous pouvez considérer qu’un pirate peut potentiellement faire tout ce que la victime peut faire via son navigateur web, une fois que la faille est exploitée.

Phishing attack illustration
Phishing attack

1. Attaques XSS stockées (Stored XSS) :

Celle-ci est assez facile à comprendre.
Tout d’abord, le pirate va envoyer un contenu malicieux dans un application web, qui va le stocker (par exemple dans une base de données). Ensuite, le contenu malicieux sera retourné dans le navigateur des autres utilisateurs lorsqu’ils iront sur le site.
Prenons pour exemple un forum, ou un blog. L’attaquant va envoyer un message ou un commentaire contenant le contenu malicieux. Lorsque les autres utilisateurs vont se rendre sur le forum ou le blog, ce contenu sera là, à chaque fois qu’ils afficheront la page.

Cette première variante des attaques XSS est appelée “stockée” car le contenu malicieux est stocké sur le serveur du site web et donc toujours retourné aux autres utilisateurs.
2. Attaques XSS reflétées (reflected XSS) :

Ce deuxième type de faille XSS ne stocke pas le contenu malicieux sur le serveur web. Le contenu est par exemple livré à la victime via une URL qui le contient (envoyée par email ou par un autre moyen):
Imaginez un site web vous permettant de voir les prévisions météo pour une ville donnée. Le nom de la ville est fourni dans l’URL de la page, comme ceci:
www.victim-website-example.com/previsionsmeteo?ville=Lyon

La page va donc vous afficher les prévisions météo pour Lyon, en réutilisant le nom de la ville qui se trouve dans l’URL, pour afficher “Voilà les prévisions météo pour Lyon :”
Le pirate pourra utiliser cette URL pour fournir un contenu malicieux comme ceci: www.victim-website-example.com/previsionsmeteo?ville=Lyon[contenu malicieux]

Avec un tel contenu dans l’URL, le serveur web va donc afficher les prévisions météo pour Lyon, mais va potentiellement aussi inclure le contenu dangereux dans la page. L’attaque est réussie.
3. Attaques basées sur le DOM (DOM based XSS) :

Cette variante est un peu plus délicate à expliquer.
La première caractéristique de cette attaque est qu’elle n’utilise pas le serveur web. Contrairement aux deux versions précédentes où le contenu était envoyé au serveur via l’URL avant d’être retourné à la victime, les attaques DOM XSS se passent directement dans le navigateur de la victime.

La possibilité pour un navigateur d’exécuter du code (comme par exemple du Javascript) est suffisant pour une attaque XSS (l’attaque ne se limite pas cependant au contexte Javascript, d’autres possibilités sont envisageables).
Cette version de XSS est particulièrement présente dans les application « web 2.0”, où une bonne quantité de code Javascript est exécutée dans le navigateur de l’utilisateur, dans interaction avec le serveur.

Penons un exemple simple:
Supposons que vous utilisez un site web qui vous permet de trouver les anagrammes d’un mot. Une telle application peut être simplement développée en Javascript, et ne nécessitera pas d’échanges avec le serveur: tous les anagrammes seront directement déterminés par le navigateur, en Javascript.
Si vous afficher la page suivante: www.victim-website-example.com/anagram_app/input/myword, celle-ci vous donnera tous les anagrammes pour “myword”.
Un pirate pourra vous envoyer l’URL suivante: www.victim-website-example.com/anagram_app/input/myword[code malicieux].
L’application Javascript d’anagrammes pourra alors interpréter le code fourni par le hacker, et si ce dernier a “bien fait son job”, l’application se comportera d’une manière non attendue, permettant différentes actions, comme le vol de vos cookies, ou encore une redirection vers un autre site.
Comment éviter de telles failles?

Quel que soit le type de faille XSS que vous considérez, toutes ces versions sont basées sur le fait que les données reçues par une application web ne peuvent pas être considérées comme sûres. Les développeurs doivent suivre des règles strictes afin de traiter les données venant de l’extérieur, qu’elles viennent d’une URL, ou bien de formulaires.
Pour les attaques de type stockées ou reflétées, tout le contenu doit être “échappé” (nettoyé) et “validé” afin de pouvoir être utilisé de manière sûre sur la page.
Pour les attaques de type DOM, le contenu doit également être encodé, avant d’être utilisé par l’application.

Les outils automatisés de détection de failles peuvent repérer certaines de ces vulnérabilités, mais un test de pénétration ou une revue de code seront plus complets.

En savoir plus sur les failles XSS:
Article OWASP sur XSS
Article OWASP sur DOM XSS

 

Autres articles dans cette série :