Chapitre 8 (suite) — XSS, CSRF & Autres Attaques Web
⏱ ~30 min autonome · ~45 min encadré
Dernier volet du chapitre web : les attaques qui ciblent le navigateur de la victime plutôt que le serveur directement, et quelques faiblesses de configuration serveur courantes.
- Distinguer XSS réfléchi, stocké et basé sur le DOM.
- Expliquer le mécanisme d'une attaque CSRF.
- Proposer des contre-mesures adaptées à chaque type d'attaque de ce chapitre.
Le XSS consiste à injecter du script malveillant (généralement JavaScript) dans une page web, exécuté ensuite dans le navigateur d'une victime qui visite cette page — contrairement à l'injection SQL, la cible finale n'est pas le serveur, mais l'utilisateur qui consulte le contenu compromis.
| Type | Mécanisme |
|---|---|
| Réfléchi | Le script malveillant fait partie de la requête elle-même (souvent dans l'URL) et n'est jamais stocké — la victime doit cliquer sur un lien spécialement conçu pour que l'attaque s'exécute. |
| Stocké | Le script malveillant est enregistré côté serveur (dans un commentaire, un profil utilisateur) et s'exécute pour chaque visiteur qui consulte le contenu infecté — plus dangereux, puisqu'aucune action spécifique de la victime n'est nécessaire au-delà de la simple consultation. |
| Basé sur le DOM | La vulnérabilité existe entièrement côté client : le script manipule le DOM de la page à partir de données non validées, sans jamais transiter par le serveur dans certains cas — plus difficile à détecter avec des outils d'analyse serveur classiques. |
Impacts
Un XSS réussi peut voler le cookie de session vu au 8.1 (usurpation de session complète), rediriger la victime vers un site malveillant, ou défigurer visuellement le contenu affiché — la gravité varie énormément selon ce que le script injecté choisit de faire une fois exécuté.
Contre-mesures
- Encodage systématique des sorties : tout contenu généré par un utilisateur et réaffiché doit être encodé pour que le navigateur l'interprète comme du texte, jamais comme du code exécutable.
- Content Security Policy (CSP) : en-tête HTTP qui restreint explicitement les sources de script autorisées à s'exécuter sur une page, limitant l'impact même si une injection réussit.
- Attribut HttpOnly sur les cookies : empêche JavaScript d'accéder directement au cookie de session, rendant son vol via XSS beaucoup plus difficile.
CSRF (falsification de requête intersite)
Le CSRF exploite la confiance qu'un site accorde au navigateur d'un utilisateur déjà authentifié : une page malveillante déclenche, à l'insu de la victime, une requête vers un site où elle est connectée (transfert bancaire, changement de courriel) — le navigateur envoie automatiquement les cookies de session valides, faisant croire au serveur que la victime a elle-même initié l'action.
Contre-mesure principale : un jeton anti-CSRF unique, généré côté serveur et inclus dans chaque formulaire légitime, que le site malveillant ne peut pas connaître ni reproduire.
Attaques sur serveurs web
Au-delà du code applicatif, le serveur web lui-même peut être mal configuré : fichiers de sauvegarde ou de configuration accessibles publiquement (rappel du Chapitre 2 sur le google dorking), répertoires listant leur contenu, ou panneaux d'administration accessibles sans restriction d'accès réseau.