Reflected XSS

On dit aussi XSS réfléchi en français, mais la terminologie anglaise prévaut souvent en ce qui concerne la SSI. Une faille XSS non permanente consiste à faire utiliser une URL contenant du script malveillant. Pour cela, il faut communiquer à un utilisateur cette URL pour qu’il clique dessus, par exemple. Rien n’est stocké sur le site web ciblé, à l’inverse d’une stored XSS.

Les champs HTML de recherche sont de bons candidats pour ce genre de faille, car ils doivent souvent laisser passer des caractères variés (par exemple en langage naturel). Comme le contenu d’un tel champ doit être passé ensuite dans une requête GET ou POST, l’absence de contrôle approprié sera forcément dommageable.

Comment piéger l’utilisateur ?

Il faut le pousser à cliquer sur un lien contenant une URL spécialement construite, qui contiendra par exemple du code malveillant en javascript qui sera exécuté sur le navigateur de la victime. L’URL sera du type :

https://lebeausitevisé.com/page/param=cecicela<script>code malveillant</script>...

Sans contrôle, les balises seront interprétées sans broncher par le navigateur… Autant une balise d’affichage comme <b>...</b> ou <i>...</i> ne posera pas de problème, autant l’exécution d’un script est une autre affaire !

Contre-mesures

Je ne (me) le répèterai jamais assez : il faut filtrer, filtrer, filtrer, autant en entrée qu’en sortie. Un framework comme Django propose des mécanismes de filtrage, autant les utiliser (ou ne pas les désactiver).

Les mesures classiques comprennent :

1. L’échappement de caractères entrée (proposé par la plupart des langages ou des frameworks servant à la création de sites web).
2. Le contrôle des affichages en particulier aux endroits où une entrée de l’utilisateur est utilisée (comme un champ de recherche).
3. Avec des contrôles supplémentaires :
   1. Sur les cookies, avec le flag HTTPOnly qui interdit notamment de lire le contenu du cookie (pour éviter le vol de session).
   2. Sur les entêtes HTTP : il existe X-XSS-Protection qui demandera au navigateur de ne pas charger une page si un XSS lui semble possible, et Content-Security-Policy qui permet de mettre en oeuvre une liste blanche de sources pour inclure du code (pour le JavaScript, les polices de caractères, les images, etc.).

Liens utiles

• CWE – CWE-79
• OWASP – A03 Injection

Voir aussi

• XSS permanente