Voler une session par XSS : la démonstration concrète
11 min · Intermédiaire · 7 août 2026
Pourquoi les quatre chapitres précédents mènent ici
Le cours sur HTTP a montré comment un cookie de session permet à un serveur de reconnaître un visiteur d’une requête à l’autre. Ce chapitre relie ce mécanisme aux trois familles de XSS vues jusqu’ici : peu importe laquelle est exploitée, une fois qu’un script s’exécute dans le navigateur d’une victime authentifiée, ce script peut tenter de lire son cookie de session.
Danger
Voler un cookie de session équivaut, pour un attaquant, à se connecter à la place de la victime, sans jamais avoir eu besoin de son mot de passe. C’est l’une des conséquences les plus graves d’une XSS.
Les étapes de l’exploitation
1. La victime se connecte normalement, le site pose un cookie de session
2. La victime charge une page contenant une charge XSS (peu importe la famille)
3. La charge lit document.cookie et envoie sa valeur vers un serveur controle par l'attaquant
4. L'attaquant reutilise cette valeur comme son propre cookie
5. Le serveur legitime ne voit aucune difference : il reconnait "la victime"La démonstration
Le bac à sable ci-dessous simule les deux bouts de la chaîne : la valeur de session que le vrai site aurait déjà posée après connexion, puis une charge XSS injectée (via innerHTML, la même faille que dans les chapitres précédents) qui la lit.
Info
Petite adaptation technique : l’isolation de ce bac à sable (invariant de sécurité de ce site) va plus loin qu’une page ordinaire, au point que document.cookie y est totalement désactivé, y compris en lecture ou en écriture. La démonstration simule donc la valeur de session via une variable JavaScript ordinaire plutôt qu’un vrai cookie : le principe de lecture et d’exfiltration reste rigoureusement identique.
<!-- HTML -->
<h3>Commentaires</h3><div id="zone"></div>
// JS
// Etape 1 : le site pose deja cette valeur de session apres connexion
// (simulee via une variable : document.cookie est desactive dans ce
// bac a sable sandboxe, voir la remarque ci-dessus)
window.cookieDeSession = "session_id=a3f9c2e1_utilisateur_authentifie";
// Etape 2 : une charge XSS injectee lit cette valeur et l'exfiltre
const commentaireInjecte = "<img src=x onerror=\"console.log('Requete envoyee vers attaquant.test : ' + window.cookieDeSession)\">";
document.getElementById('zone').innerHTML = commentaireInjecte;En réalité, cette dernière ligne serait un appel réseau silencieux (fetch(...) ou new Image().src = ...) vers un serveur que l’attaquant contrôle, jamais visible pour la victime. Ce bac à sable se contente de l’afficher en clair dans la console, pour rendre la fuite visible.
Le seul détail qui aurait tout changé
Si ce cookie avait été posé avec l’attribut HttpOnly (vu dans le cours sur HTTP), la ligne document.cookie à l’intérieur du script injecté n’aurait tout simplement pas contenu session_id : la valeur reste invisible à JavaScript, quelle que soit la faille XSS exploitée par ailleurs.