Attaques XSS : la menace invisible dans le navigateur

Comprendre le XSS

Il y a XSS lorsque des données non fiables sont interprétées comme du contenu exécutable dans une page. Le script tourne sous l'origine de cette page : il peut agir sur son DOM et souvent envoyer des requêtes au site au nom de la personne connectée. La politique de même origine limite toujours l'accès aux autres sites. Un cookie marqué HttpOnly ne peut pas être lu avec document.cookie, même si le script peut encore agir dans une page où la personne est connectée.

L'attribut SameSite règle surtout l'envoi des cookies lors de requêtes entre sites. Il peut limiter certains risques de falsification de requêtes, mais ne supprime pas un script qui tourne déjà dans la page du site. La documentation MDN sur Set-Cookie distingue les rôles de SameSite et de HttpOnly.

Imagine le panneau d'affichage d'une entreprise. Un visiteur peut y laisser une note, mais ne devrait pas pouvoir modifier les consignes ou les commandes du panneau. Le XSS revient à traiter sa note comme si elle faisait partie du panneau lui-même. La frontière cède lorsque les données sont insérées à un endroit où le navigateur peut les exécuter.

Trois principaux types, et quelques cas voisins

Ces trois catégories indiquent où les données non fiables entrent dans la page et deviennent exécutables. Elles peuvent se recouper : un serveur peut fournir des données que le code du navigateur place ensuite dans une partie dangereuse du DOM.

XSS stocké. L'application conserve un contenu contrôlé par l'attaquant, par exemple dans un commentaire, un profil ou un ticket d'assistance, puis l'affiche à d'autres personnes. L'exposition dépend de celles qui peuvent le voir et de la façon dont il est affiché.

XSS réfléchi. Le serveur insère dans sa réponse une donnée issue de la requête, souvent un paramètre d'URL, sans l'encoder correctement pour son emplacement dans la page. Un lien fabriqué par l'attaquant peut conduire quelqu'un vers cette réponse.

XSS fondé sur le DOM. Le code du navigateur lit une donnée non fiable et la transmet à une opération dangereuse sur le DOM, comme innerHTML. Cette donnée peut venir d'une URL, d'une réponse du serveur ou d'une autre source. Le point décisif est sa transformation dangereuse dans le navigateur. Consulte le guide OWASP sur le XSS fondé sur le DOM.

Le self-XSS est différent : l'attaquant convainc une personne d'exécuter elle-même du code, par exemple en le collant dans les outils de développement. Les XS-Leaks déduisent des informations d'autres origines à partir d'effets observables : c'est une autre famille de failles. Ces termes ne doivent pas masquer le problème central du XSS : une donnée non fiable devient active dans une page de confiance.

Les étapes d'une attaque XSS

Un déroulement typique montre où l'application peut interrompre l'attaque.

1. 1

   Trouver une entrée

   L'attaquant repère un commentaire, un paramètre d'URL, un message ou une autre donnée qui finit par apparaître dans une page.
2. 2

   Atteindre un emplacement dangereux

   L'application insère cette donnée à un endroit où le navigateur peut la traiter comme du HTML ou du script plutôt que comme du texte.
3. 3

   Faire parvenir le contenu injecté

   L'attaquant amène quelqu'un à ouvrir la page touchée, par un lien fabriqué ou un contenu partagé.
4. 4

   Exécuter le code dans la page touchée

   Si le navigateur l'exécute, le code injecté partage l'origine de la page et peut agir sur les contenus et interfaces disponibles, dans les limites imposées par le navigateur et le site.
5. 5

   Abuser des accès disponibles

   Selon l'application, le code peut modifier la page, lire des données exposées ou envoyer des requêtes avec la session en cours. La réussite dépend des protections du site.

Ce que le code injecté peut faire

Le XSS peut avoir d'autres effets qu'une simple modification visible de la page. Son impact dépend des informations et des actions accessibles dans celle-ci. Ces quatre possibilités illustrent la diversité des conséquences, sans les classer par fréquence.

Actions sur le compte. Le code injecté peut envoyer des requêtes depuis une page où la personne est connectée et lire les jetons que l'application rend accessibles à JavaScript. HttpOnly empêche de lire directement les cookies concernés, sans bloquer à lui seul les actions sur le même site. Consulte la documentation MDN sur les cookies.

Collecte d'identifiants. Un formulaire modifié peut recueillir un mot de passe ou d'autres données au moment où la personne les saisit. Cela suppose qu'elle les entre dans cette page : un XSS ne révèle pas automatiquement un mot de passe enregistré ailleurs.

Modification de la page. Le code peut changer les liens, les consignes ou les détails d'une opération montrés à la personne. Il peut aussi charger d'autres ressources web dans les limites des règles du site. L'exécution d'un logiciel malveillant sur l'appareil exigerait une étape distincte, comme l'exploitation d'une faille du navigateur ou l'ouverture d'un fichier téléchargé.

Exposition de données. Le script peut lire les informations déjà présentes dans la page et les envoyer ailleurs si les contrôles réseau le permettent. La politique de même origine limite toujours la lecture d'autres sites. Les données sensibles et les droits du site touché restent le problème.

Cinq scénarios illustratifs

Ces exemples sont hypothétiques, pas des comptes rendus d'incidents réels. Chacun montre où vérifier la frontière entre données et code.

Site communautaire. L'aperçu d'un commentaire affiche le HTML envoyé comme du contenu actif. Si une personne chargée de la modération ouvre cet aperçu pendant qu'elle est connectée, le code injecté pourrait agir dans l'interface de modération. Il faut corriger l'affichage et examiner ce parcours doté de droits élevés.

Boutique en ligne. Un terme de recherche est repris dans une réponse HTML sans encodage adapté. Une personne qui suit un lien fabriqué par l'attaquant pourrait voir un lien de paiement modifié. Le domaine légitime ne suffit pas à prouver que le lien affiché est sûr.

Portail de santé. Un message enregistré s'affiche dans le navigateur d'un soignant. Même avec des cookies HttpOnly, le code injecté pourrait lire les informations déjà présentes sur cette page ou envoyer des requêtes que le soignant est autorisé à faire. Les droits d'accès et la sécurité de l'affichage comptent tous deux.

Tableau de bord financier. Le code du navigateur lit un fragment d'URL et l'insère dans innerHTML. Un lien malveillant pourrait modifier ce que voit une personne. Les vérifications des opérations côté serveur et leur confirmation peuvent néanmoins bloquer un virement non autorisé. La faille du DOM doit aussi être corrigée.

Site d'information publique. Un ancien modèle de publication traite un champ de titre comme du HTML de confiance. Une personne malveillante disposant d'un compte de rédaction, ou un compte compromis, pourrait modifier les consignes publiques. Il faut examiner les anciens modèles autant que les composants récents, ainsi que les droits permettant de les alimenter.

Pourquoi le XSS persiste

Les bibliothèques modernes encodent de nombreuses valeurs par défaut. On peut pourtant contourner ces protections avec du HTML brut, des opérations dangereuses sur le DOM, des raccourcis dans les modèles ou du code tiers. L'OWASP classe l'injection, dont le XSS, parmi les risques des applications web. Son guide de prévention du XSS explique pourquoi aucune mesure ne couvre tous les contextes.

Les grandes applications mêlent anciens modèles, composants récents, texte enrichi fourni par les utilisateurs et scripts tiers. La bonne correction dépend du point d'entrée et de l'emplacement final : texte HTML, attribut, URL, bloc de script et opération sur le DOM obéissent à des règles différentes. Les outils automatisés aident, mais des tests limités aux réponses du serveur peuvent manquer les transformations effectuées dans le navigateur. Ajoute des tests dans celui-ci et des revues de code pour les parcours qui manipulent des données non fiables.

Réduire son exposition au quotidien

Tu ne peux pas corriger la faille d'un site que tu consultes, mais tu peux limiter ce que tu y exposes. Ces gestes réduisent certains risques sans garantir une protection contre le XSS.

Vérifie l'adresse du site avant de saisir tes identifiants ou de confirmer une action sensible. Garde ton navigateur à jour et supprime les extensions inutiles. Sépare les comptes ou profils lorsque tes activités n'ont pas le même niveau de confiance. Si un site semble compromis, déconnecte-toi et vérifie l'activité de ton compte depuis un appareil sûr ; la déconnexion ne ferme pas forcément les autres sessions. Browser.lol peut exécuter le code du site dans un navigateur distant, mais un XSS peut encore toucher la session de ton compte et les données que tu saisis ou approuves. Le visualiseur, le presse-papiers et les téléchargements relient aussi la session à ton appareil.

Mesures pour les équipes de développement et de sécurité

La prévention se joue dans l'application. Commence par ces cinq mesures et vérifie-les dans les contextes que ton application utilise réellement.

Encoder selon le contexte de sortie. Texte HTML, attributs, URL, JavaScript et CSS demandent des traitements différents. Préfère les interfaces qui insèrent du texte brut lorsque c'est ce qu'il te faut. Si du HTML enrichi est nécessaire, utilise un outil d'assainissement maintenu.

Utiliser consciemment les protections du framework. React, Vue et Angular peuvent encoder les valeurs affichées. Les fonctions qui insèrent du HTML brut et les modifications directes du DOM contournent une partie de cette protection. Examine-les de près.

Déployer une politique CSP restrictive. Une Content Security Policy bien conçue, fondée sur des valeurs nonce ou des empreintes, peut limiter l'exécution d'un script après une injection. Elle complète l'encodage et l'assainissement, sans les remplacer. Consulte le guide OWASP sur la CSP.

Suivre les données et repérer les opérations dangereuses. L'analyse statique peut signaler des usages risqués, comme une affectation à innerHTML sans vérification. Associe-la à des tests des pages affichées et des chemins de données côté navigateur.

Examiner les parcours dotés de droits élevés. Teste les endroits où le personnel voit du contenu fourni par les utilisateurs, ceux qui acceptent du texte enrichi et les pages qui déclenchent des actions sensibles. Tester dans un navigateur distant peut réduire l'exposition locale au code web, sans rendre une démonstration d'attaque inoffensive. Utilise des comptes de test et évite les vrais secrets.

Empêcher les données de devenir du code

Le XSS naît d'une frontière mal tenue dans l'application. L'encodage adapté au contexte, les opérations sûres sur le DOM, le traitement prudent du texte enrichi et une politique CSP restrictive réduisent le risque que des données non fiables deviennent du code. Les attributs des cookies et les contrôles côté serveur peuvent limiter certaines conséquences, sans guérir toutes les failles XSS.

Un navigateur distant change le lieu où s'exécute le code d'un site. Il ne corrige ni ce site ni les actions effectuées dans une session de compte distante. Sépare les comptes sensibles, vérifie les actions importantes et corrige à la source le passage des données au code. Ces protections se complètent, car elles agissent sur des parties différentes du risque.