Le Cross-Site Scripting (XSS) : Comprendre, détecter et contrer la faille web omniprésente
Cet article fait partie de la série Les types de failles informatiques : classement par sévérité et guide complet.
Niveau de sévérité dans cette série : Moyenne. Classification indicative (permet d’exécuter du code dans le navigateur d’autres utilisateurs d’un site vulnérable) ; la gravité réelle d’une faille dépend toujours du contexte précis et, idéalement, de son score CVSS.
Dans le domaine de la sécurité des applications web, le Cross-Site Scripting (abrégé XSS) figure parmi les vulnérabilités les plus répandues et les plus tenaces. Contrairement aux failles ciblant directement les bases de données ou les serveurs d’hébergement, le XSS exploite la confiance qu’accorde le navigateur d’un utilisateur au site web qu’il consulte.
En injectant du code exécutable côté client, un attaquant peut intercepter des informations confidentielles, manipuler l’affichage de la page ou usurper l’identité de ses victimes. Cet article détaille l’origine de cette menace, ses différentes formes techniques, des cas réels marquants ainsi que les contre-mesures indispensables pour s’en préserver.
Origine
Le terme « Cross-Site Scripting » a été formalisé au début de l’année 2000 par des ingénieurs en sécurité de la société Microsoft, en concertation avec le CERT. Les premiers cas documentés remontent à la fin de l’année 1999, lorsque des chercheurs ont observé que des balises de script malveillantes insérées dans des formulaires ou des paramètres d’URL pouvaient s’exécuter dans le contexte de sécurité d’un autre site web.
L’abréviation XSS a été privilégiée à l’acronyme CSS afin d’éviter toute confusion avec les feuilles de style en cascade (Cascading Style Sheets). À l’origine, le nom reflétait spécifiquement les attaques permettant à un site malveillant d’exécuter un script au sein d’un autre domaine. Au fil des évolutions du Web, la définition s’est élargie à toute forme d’injection de code côté client exécuté par le navigateur de la victime.
Définition
Le Cross-Site Scripting survient lorsqu’une application web intègre des données fournies par un utilisateur dans une page web renvoyée au navigateur, sans les valider ni les échapper correctement. Le navigateur interprète alors ces données non nettoyées comme du code légitime, généralement écrit en JavaScript.
Une fois le script exécuté dans le contexte de la session de la victime, l’attaquant peut accéder aux jetons d’authentification, aux cookies de session, lire des informations sensibles affichées à l’écran ou exécuter des actions au nom de l’utilisateur. On distingue principalement trois variantes de XSS :
Le XSS réfléchi (Reflected XSS)
Dans cette configuration, le charge utile (payload) malveillant est inclus dans la requête HTTP envoyée au serveur (par exemple via un paramètre de recherche ou un lien piégé). Le serveur reflète immédiatement ce contenu dans la réponse HTML envoyée au navigateur sans le neutraliser. L’attaque nécessite que la victime clique sur un lien spécialement conçu par l’attaquant.
Le XSS stocké (Stored XSS)
Aussi appelée XSS persistant, cette forme est la plus dangereuse. Le code malveillant est enregistré de manière permanente sur le serveur cible (dans une base de données, un champ de profil, un forum de discussion ou une zone de commentaires). Chaque utilisateur qui consulte la page infectée subit automatiquement l’exécution du script, sans interaction spécifique préalable.
Le XSS basé sur le DOM (DOM-based XSS)
Dans une attaque XSS basée sur le Document Object Model (DOM), le serveur n’intervient pas directement dans la réinjection du script. La vulnérabilité réside entièrement dans le code JavaScript exécuté côté client, qui lit une source non sécurisée (comme l’URL de la page) et écrit de manière imprudente cette donnée dans le DOM de la page web.
Pourquoi une sévérité moyenne ?
Au sein de notre classification des failles informatiques, le Cross-Site Scripting est positionné à un niveau de sévérité Moyenne. Sur l’échelle du système standardisé CVSS (Common Vulnerability Scoring System), les vulnérabilités XSS obtiennent généralement un score situé entre 4.0 et 6.9. En effet, le XSS n’entraîne pas directement la prise de contrôle du serveur ou la compromission totale de la base de données sous-jacente (contrairement aux injections SQL ou aux exécutions de code à distance). Néanmoins, son impact sur l’intégrité et la confidentialité des sessions utilisateur reste significatif, en particulier lorsque le compte compromis appartient à un administrateur du système.
Exemples réels
L’histoire de la sécurité web est jalonnée d’incidents majeurs démontrant le potentiel dévastateur du Cross-Site Scripting :
- Le ver Samy sur MySpace (octobre 2005) : Développé par le chercheur Samy Kamkar, ce ver exploitait une faille XSS stockée dans la gestion des profils du réseau social MySpace. En contournant les filtres HTML et CSS de la plate-forme, le script injecté forçait chaque visiteur du profil infecté à ajouter Samy comme ami, à afficher la phrase « but most of all, Samy is my hero » sur son propre profil, tout en y répliquant le code malveillant. En moins de 20 heures, le ver s’est propagé à plus d’un million de profils, devenant le ver informatique à la propagation la plus rapide de l’histoire du Web.
- Injection XSS dans les annonces eBay (septembre 2014) : Des pirates ont exploité une vulnérabilité XSS stockée sur le site marchand eBay. La plateforme autorisait le « contenu actif » (code JavaScript dans le descriptif des produits). Les attaquants ont injecté des scripts au sein d’annonces de vente d’objets populaires. Lors de la consultation de l’annonce, le script redirigeait de manière transparente les acheteurs vers une fausse page de connexion hébergée sur un serveur externe afin de dérober leurs identifiants et leurs cookies de session.
Comment s’en protéger
La neutralisation des failles XSS repose sur une approche de défense en profondeur combinant plusieurs bonnes pratiques reconnues par les organismes de référence tels que l’OWASP, le MITRE et le NIST :
- Échappement et encodage contextuel des sorties : Toutes les données saisies par un utilisateur doivent être obligatoirement encodées avant d’être affichées dans une page web (conversion des caractères spéciaux comme
<,>,",'et&en leurs équivalents d’entités HTML). - Validation et assainissement des entrées (Sanitization) : Appliquer des règles strictes sur les données reçues côté serveur. Si du contenu HTML riche doit impérativement être accepté (éditeurs WYSIWYG), il faut utiliser une bibliothèque d’assainissement éprouvée (ex. DOMPurify) pour filtrer les balises et attributs dangereux.
- Mise en place d’une politique de sécurité du contenu (Content Security Policy – CSP) : L’en-tête HTTP
Content-Security-Policypermet de restreindre l’exécution de scripts aux seules sources approuvées et d’interdire l’exécution de scripts en ligne (inline scripts). - Protection des cookies avec la directive
HttpOnly: La configuration de l’attributHttpOnlysur les cookies d’authentification empêche les scripts JavaScript d’y accéder via l’objetdocument.cookie, limitant ainsi les risques de vol de session en cas d’injection XSS.
Avez-vous déjà été confronté à une faille XSS lors du développement ou de l’audit d’une application web, et quelle méthode de protection s’est révélée la plus efficace selon vous ?
Photo : Bibek ghosh sur Pexels.
Pour aller plus loin
Liens affiliés Amazon : en tant que Partenaire Amazon, ce site perçoit une commission sur les achats éligibles réalisés via ces liens, sans coût supplémentaire pour vous.
Sécurité informatique – Ethical Hacking : Apprendre l’attaque pour mieux se défendre, Collectif d’auteurs
Un ouvrage de référence abordant en détail les mécanismes des attaques web, y compris les injections XSS, et leurs contre-mesures.
Ce livre guide les développeurs et administrateurs dans l’implémentation de défenses concrètes contre les vulnérabilités de l’OWASP Top 10.
Voir aussi
- Zero-Day : la faille que personne ne voit venir (Critique)
- L’Exécution de Code à Distance (RCE) : Comprendre, Prévenir et Contrôler la Faille Ultime (Critique)
- L’Élévation de Privilèges (Privilege Escalation) : Comprendre et Prévenir la Prise de Contrôle Absolue (Élevée)
- Le Rançongiciel (Ransomware) : Anatomie, Histoire et Stratégies de Protection (Élevée à Critique)
- Le Débordement de Tampon (Buffer Overflow) : Comprendre la Faille Légendaire de la Cybersécurité (Élevée)
- L’Injection SQL (SQLi) : fonctionnement, failles historiques et bonnes pratiques de protection (Élevée)
- L’Attaque de l’Homme du Milieu (Man-in-the-Middle) : comprendre et contrer les interceptions de trafic (Moyenne)
- Le Cross-Site Request Forgery (CSRF) : comprendre et contrer le piège de la session compromise (Faible à Moyenne)
- L’Ingénierie Sociale et le Phishing : Anatomie de la Première Porte d’Entrée des Cyberattaques (Variable (vecteur d’entrée n°1))
- Toutes les failles informatiques classées par sévérité
