La banque fictive espace.banquesilex.example protège ses virements par un jeton anti-CSRF... mais ce jeton est statique : la valeur csrf_token est identique pour tous les utilisateurs et toutes les sessions. Le cookie de session est en plus posé avec SameSite=None, donc il accompagne même les requêtes intersite — un jeton prévisible devient alors forgeable.
Une capture réseau d'une vingtaine de virements est fournie (ci-dessous). La plupart sont légitimes (émis depuis le domaine de la banque, Sec-Fetch-Site: same-origin). Une seule requête a été forgée : elle provient d'un site tiers (Origin/Referer externes, Sec-Fetch-Site: cross-site) mais réutilise le même jeton statique — et le serveur l'a acceptée.
Chaque réponse contient un en-tête X-Audit-Ref. Toutes ces valeurs sont homogènes (même longueur, même préfixe) : impossible de repérer la bonne à l'œil. Identifiez d'abord la requête malveillante par ses en-têtes, puis décodez son X-Audit-Ref : il contient le flag.
Les X-Audit-Ref ne sont pas en clair : ils sont chiffrés par XOR avec une clé répétée. Or cette clé n'est autre que le jeton statique — connu de tous, justement parce qu'il ne change jamais.Leçon de sécurité
Le CSRF force un utilisateur authentifié à exécuter une action à son insu. Un jeton anti-CSRF doit être unique par session, imprévisible et vérifié côté serveur. Complétez par l'attribut cookie SameSite=Strict/Lax, la vérification de l'en-tête Origin, et une ré-authentification pour les actions sensibles (virements).