Le Cross-Site Request Forgery (CSRF) n'est pas une simple erreur de code, mais une exploitation directe de la conception fondamentale des navigateurs web. Il cible l'intégrité des actions d'un utilisateur authentifié.
Les navigateurs ont été conçus pour faciliter le partage de ressources. Pour maintenir une session utilisateur, ils injectent automatiquement les cookies d'un domaine dans chaque requête sortante vers ce même domaine. L'application cible considère alors que toute requête reçue avec un cookie valide est légitime.
Le CSRF permet à l'attaquant de "devenir" l'utilisateur pour une fraction de seconde, lui permettant de :
Pour comprendre le CSRF, il faut analyser comment le navigateur gère l'état (State) dans un protocole HTTP nativement "stateless".
Par design, un site tiers (ex: malicious-site.com) peut inclure des instructions HTTP pointant vers un autre site (ex: bank.com). Le navigateur traitera la requête et y joindra les cookies de session de bank.com sans se soucier du fait que l'ordre vient de malicious-site.com.
La Same-Origin Policy (SOP) protège la lecture des données, pas l'écriture. Elle empêche malicous.com de lire le contenu de votre compte bancaire, mais elle n'empêche pas malicious.com d'envoyer un ordre de virement. C'est pourquoi le CSRF est dit "aveugle" : l'attaquant lance la flèche, mais ne peut pas voir si elle a touché la cible via la réponse HTTP.
L'exploitation se fragmente en deux vecteurs principaux selon la méthode HTTP ciblée par l'application vulnérable.
C'est la méthode la plus classique. L'attaquant héberge un formulaire dont les champs correspondent à l'action visée, et utilise du JavaScript pour le soumettre automatiquement dès le chargement de la page.
<body onload="document.forms[0].submit()">
<form action="https://victim.com/api/settings" method="POST">
<input type="hidden" name="email" value="hacker@arasaka.corp" />
</form>
</body>
Si l'application utilise des paramètres GET pour des actions d'écriture (ex: /delete_user?id=123), l'attaque devient triviale. Une simple balise <img> ou <iframe> suffit à déclencher l'action.
<img src="https://app.com/transfer?to=99&amount=5000" style="display:none">
Le Synchronizer Token Pattern (STP) est la défense standard recommandée par l'OWASP. Elle consiste à insérer une preuve d'intention dans chaque requête sensible.
Avec les API REST, les SPA et les en-têtes personnalisés, la surface d'attaque et les défenses ont évolué.
Les requêtes AJAX/Fetch permettent d'ajouter des en-têtes comme X-CSRF-Token. Le navigateur impose un CORS Preflight (OPTIONS) avant d'autoriser un tel en-tête vers un autre domaine. L'attaquant ne peut pas contourner cette phase sans configuration CORS permissive sur le serveur.
Une méthode où le secret est stocké à la fois dans un cookie et dans un paramètre POST. Le serveur compare les deux valeurs. C'est efficace mais attention : si un attaquant peut écrire des cookies sur un sous-domaine (via XSS), il peut contourner cette protection.