Cross-Site Request Forgery (CSRF) — Vue d'ensemble

Qu'est-ce que le Cross-Site Request Forgery#

Le Cross-Site Request Forgery (CSRF, CWE-352) est une vulnérabilité web qui force les utilisateurs authentifiés à exécuter des actions modifiant l'état qu'ils n'ont pas initiées. Contrairement au XSS, l'attaquant n'a pas besoin d'accéder au token de session de la victime — le mécanisme d'envoi automatique de cookies du navigateur fait le travail. Quand la victime visite la page de l'attaquant, le navigateur inclut silencieusement tous les cookies de session valides pour le domaine cible sur toute requête embarquée, et le serveur cible traite cette requête comme si elle provenait de l'utilisateur.

Le CSRF a été retiré de l'OWASP Top 10 en 2021 en supposant que les cookies SameSite, désormais défaut sous Chrome 80+ et la plupart des navigateurs modernes, élimineraient la plupart des vecteurs. En pratique, la menace n'a pas disparu : CVE-2024-20252 (Cisco Expressway, CVSS 9.6, février 2024) et CVE-2024-23897 (Jenkins CLI, CVSS 9.8, catalogue CISA KEV, janvier 2024) reposent tous deux sur le CSRF comme vecteur primaire ou facilitateur. Un audit 2024 a révélé que seulement 3,52 % des sites web avaient un attribut SameSite défini, ce qui signifie que la grande majorité des applications en production fonctionnent encore sans cette défense.

Trois conditions doivent être simultanément vraies pour qu'une attaque CSRF réussisse : (1) une action privilégiée modifiant l'état existe — changement de mot de passe, virement de fonds, création de compte, opération administrative ; (2) l'application authentifie l'utilisateur exclusivement via des cookies, sans vérification complémentaire comme un en-tête personnalisé ou un token CSRF ; et (3) tous les paramètres de requête nécessaires à l'exécution de l'action sont prévisibles ou connus de l'attaquant. Quand ces trois conditions sont réunies, l'attaquant peut construire une page qui déclenche l'action avec une seule visite de la victime.

Comment fonctionne le CSRF#

La Same-Origin Policy du navigateur empêche JavaScript de lire les réponses cross-origin, mais elle n'empêche pas les requêtes cross-origin d'être envoyées. Une page sur evil.com peut amener le navigateur à effectuer une requête GET ou POST vers bank.com, et le navigateur joint dûment les cookies de bank.com. Le serveur reçoit une requête syntaxiquement valide et authentifiée sans indication qu'elle provient d'une page hostile.

L'attaque se déroule en cinq étapes :

1. La victime s'authentifie auprès de banque.com — cookie de session défini.
2. La victime visite evil.com (page contrôlée par l'attaquant), via phishing ou une publicité embarquée.
3. La page de l'attaquant contient un formulaire caché ou une balise image ciblant un endpoint modifiant l'état sur banque.com.
4. Le navigateur déclenche la requête automatiquement (au chargement de la page, ou sans aucune interaction utilisateur au-delà de la visite).
5. banque.com reçoit la requête, valide le cookie de session, ne trouve aucune vérification de token CSRF, et exécute l'action.

La règle RFC 9110 §9.2 sur les méthodes sûres stipule que les requêtes GET NE DOIVENT PAS modifier l'état du serveur. Les exploits CSRF basés sur GET ciblent les applications qui violent cette règle — un anti-pattern courant dans le code hérité, les panneaux d'administration avec des liens d'action rapide, et les endpoints de déconnexion.

Variantes d'attaque#

Matrice des cookies SameSite#

Comprendre quand les cookies sont envoyés en intersite est fondamental pour comprendre la surface d'attaque :

Exemples réels#

CVE-2024-20252 / CVE-2024-20254 — Cisco Expressway Series (CVSS 9.6, Critique) : Des protections CSRF insuffisantes sur l'API web Cisco Expressway permettaient à un attaquant distant non authentifié de tromper un administrateur authentifié pour qu'il suive un lien forgé. L'attaque déclenchait des modifications de configuration arbitraires, la création de comptes avec des privilèges élevés et des conditions de DoS — le tout au niveau de privilège de l'administrateur. CVE-2024-20254 était exploitable dans la configuration par défaut. Publié en février 2024, patch requis, aucune solution de contournement.

CVE-2024-23897 — Jenkins CLI (CVSS 9.8, CISA KEV, Critique) : L'analyseur CLI args4j de Jenkins remplaçait les arguments @<chemin_fichier> par le contenu du fichier. Des attaquants lisaient /var/jenkins_home/secrets/master.key de manière non authentifiée, extrayaient le secret de token CSRF, forgeaient des tokens CSRF valides et exécutaient des actions CLI privilégiées sans aucune interaction utilisateur au-delà de l'exploit initial. Ajouté au catalogue CISA KEV en août 2024 avec une échéance de patch obligatoire au 9 septembre 2024.

CVE-2024-4994 — GitLab CE/EE GraphQL (CVSS 8.1, Élevé) : CSRF sur l'endpoint /api/graphql permettait à des attaquants non authentifiés d'exécuter des mutations GraphQL arbitraires au nom de victimes authentifiées. GraphQL acceptait des mutations via des types de contenu qui ne déclenchaient pas de preflight CORS, contournant la protection supposée. HackerOne #1122408 (prime de 3 370 $) a documenté le vecteur de mutation via requête GET sur le même endpoint.

HackerOne #1497169 — GitHub Enterprise Management Console (10 000 $) : La prime CSRF la plus élevée connue sur HackerOne. L'attaque contournait la protection CSRF dans la console de gestion du serveur GitHub Enterprise, permettant des actions administratives arbitraires sur l'infrastructure enterprise.

Détection#

Tests manuels#

1. Identifier les endpoints modifiant l'état — journaliser toutes les requêtes POST/PUT/PATCH/DELETE plus tout GET qui modifie des données (chercher delete, update, transfer, create dans les chemins).
2. Vérifier la présence du token CSRF — inspecter chaque requête pour un champ csrf_token, authenticity_token, _token, __RequestVerificationToken ou XSRF-TOKEN.
3. Tester l'omission du token — supprimer entièrement le champ token du corps de la requête et resoumettre. Une réponse 2xx sans message d'erreur confirme que le serveur accepte les requêtes sans token.
4. Tester les tokens vides et aléatoires — soumettre avec un token vide, puis avec une valeur aléatoire de même longueur. Toute acceptation confirme l'absence de validation réelle.
5. Tester le token d'un autre utilisateur — utiliser un token valide d'une session authentifiée différente. L'acceptation confirme que le token n'est pas lié à la session.
6. Tester le contournement Content-Type — pour les APIs JSON, renvoyer la requête avec Content-Type: text/plain et observer si le serveur analyse encore et exécute le corps.
7. Tester l'attribut SameSite — inspecter les en-têtes Set-Cookie. Relever la valeur SameSite (ou son absence). Tester les endpoints GET modifiant l'état directement via navigation de premier niveau.
8. Tester le remplacement de méthode — ajouter ?_method=POST ou l'en-tête X-HTTP-Method-Override: POST aux requêtes GET ciblant des endpoints POST. Les frameworks comme Symfony, Rails et Laravel acceptent ces overrides.
9. Générer et tester un PoC — Burp Suite Pro : clic droit sur la requête → Engagement tools → Generate CSRF PoC. Charger dans un navigateur avec une session victime active.

Détection automatisée#

Le générateur de PoC CSRF de Burp Suite Pro identifie la surface d'attaque ; la règle 20012 d'OWASP ZAP signale les tokens manquants. XSRFProbe effectue une analyse approfondie des tokens incluant l'omission, le token vide, le token aléatoire et la réutilisation entre utilisateurs. Les scanners automatisés ratent les vulnérabilités de token non lié à la session (réutilisation de token entre utilisateurs) et les chaînes de contournement SameSite nécessitant une exploitation en plusieurs étapes.

BreachVex détecte le CSRF via plusieurs techniques complémentaires : analyse de token de formulaire avec sonde d'API JSON, sonde POST cross-origin avec comparaison de référence et logique de saut sensible aux segments, et sonde GET différentielle qui détecte la divergence de réponse entre requête authentifiée et non authentifiée.

Prévention#

Token synchroniseur (Défense primaire)#

Générer un token aléatoire cryptographiquement lié à la session par session utilisateur. L'intégrer dans chaque formulaire modifiant l'état. Le valider côté serveur à chaque requête modifiant l'état, rejetant les requêtes qui l'omettent ou présentent un token invalide.

# FastAPI — génération et validation du token CSRF
import secrets
from fastapi import Request, HTTPException, Form
 
def generate_csrf_token() -> str:
    return secrets.token_urlsafe(32)  # 256 bits d'entropie
 
def validate_csrf_token(request: Request, csrf_token: str = Form(...)):
    session_token = request.session.get("csrf_token")
    if not session_token or not secrets.compare_digest(session_token, csrf_token):
        raise HTTPException(status_code=403, detail="Token CSRF invalide ou manquant")

Utiliser secrets.compare_digest (comparaison en temps constant) pour prévenir les attaques oracle de timing. Les tokens doivent être uniques par session, pas par requête — les tokens par requête cassent les applications multi-onglets.

Cookies SameSite=Strict (Défense en profondeur)#

Définir SameSite=Strict sur les cookies de session pour bloquer toutes les requêtes intersites, y compris la navigation de premier niveau. Utiliser le préfixe de cookie __Host- pour prévenir les attaques d'injection depuis les sous-domaines.

Set-Cookie: __Host-SID=<token>; Path=/; Secure; HttpOnly; SameSite=Strict

__Host- exige Secure, Path=/ et aucun attribut Domain — empêchant les sous-domaines d'injecter un cookie correspondant qui pourrait contourner les schémas de double cookie soumis.

En-têtes Fetch Metadata (Défense moderne)#

Implémenter une politique d'isolation de ressources utilisant les en-têtes Sec-Fetch-Site, que les navigateurs modernes joignent à toutes les requêtes (couverture 98%+ mondiale en 2025) :

# FastAPI — politique d'isolation de ressources
METHODES_SURES = {"GET", "HEAD", "OPTIONS"}
SITES_AUTORISES = {"same-origin", "same-site", "none"}
 
def resource_isolation_policy(request: Request):
    site = request.headers.get("Sec-Fetch-Site", "")
    mode = request.headers.get("Sec-Fetch-Mode", "")
    dest = request.headers.get("Sec-Fetch-Dest", "")
 
    if request.method in METHODES_SURES or site in SITES_AUTORISES:
        return
    if mode == "navigate" and dest not in ("object", "embed"):
        return  # Autoriser la navigation navigateur de premier niveau
 
    raise HTTPException(status_code=403, detail="Requête intersite rejetée")

BREACH et oracles de compression de tokens#

Les tokens CSRF peuvent être révélés via BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) lorsque le serveur compresse des réponses contenant à la fois le token et une entrée contrôlée par l'attaquant dans le même corps. L'oracle de compression Huffman révèle le token caractère par caractère via des mesures de longueur de texte chiffré. Atténuation : utiliser le masquage de token par requête (nonce XOR, tel qu'implémenté par la librairie csrf-csrf), ou désactiver la compression HTTP sur les réponses transportant des secrets.

Ressources#

• OWASP CSRF Prevention Cheat Sheet
• PortSwigger : Qu'est-ce que le CSRF ?
• CWE-352 : Cross-Site Request Forgery
• RFC 9700 — OAuth 2.0 Security Best Current Practice

Sujets connexes#

• XSS — Cross-Site Scripting : Le XSS peut voler des tokens CSRF via XMLHttpRequest ; le Login CSRF s'enchaîne avec le XSS stocké pour la prise de contrôle de compte.
• Session Fixation : Le Login CSRF et la fixation de session partagent la surface d'exploitation pré-authentification.
• SSRF : Le CSRF et le SSRF exploitent tous deux des canaux de confiance — le CSRF cible l'agent utilisateur, le SSRF cible la pile sortante du serveur.
• Open Redirect : Les redirections ouvertes sur le domaine cible permettent le contournement SameSite=Strict en convertissant des requêtes intersites en navigation same-site.