CSRF : agir à votre insu pendant que vous êtes connecté

Le principe

Quand vous êtes connecté à un site, votre navigateur envoie automatiquement votre cookie de session à chaque requête vers ce site — même si cette requête part d’une page totalement différente ouverte dans un autre onglet.

CSRF (Cross-Site Request Forgery) exploite exactement ça : un site piégé déclenche discrètement une action sur le site où vous êtes connecté, et votre navigateur y joint gentiment votre cookie. Aux yeux du serveur, l’action semble venir de vous, en toute légitimité.

Un exemple concret

Une page piégée contient un formulaire invisible qui se soumet tout seul vers banque.exemple.fr/virement avec un montant et un IBAN destinataire déjà remplis. Si vous êtes connecté à votre compte dans un autre onglet au moment où vous visitez cette page, et que le site ne vérifie rien d’autre que la présence du cookie, le virement part — vous n’avez rien cliqué, rien vu.

Autre variante fréquente : un lien de « désinscription » ou de « suppression de compte » envoyé par e-mail, cliqué par curiosité, qui déclenche l’action immédiatement sans aucune confirmation.

Pourquoi c’est grave

Contrairement au vol de mot de passe, CSRF n’a besoin d’AUCUN accès à votre compte : il détourne une session déjà ouverte, la vôtre. Toute action qui change un état — changer un e-mail de contact, supprimer un compte, valider une commande, modifier des droits administrateur — est une cible potentielle.

OWASP classe cette faille sous A01:2021 – Contrôle d’accès défaillant. Sur un panneau d’administration mal protégé, une seule requête CSRF bien ciblée peut suffire à créer un compte administrateur pour l’attaquant.

Comment s’en protéger

Chaque formulaire qui modifie une donnée doit inclure un jeton anti-CSRF unique et imprévisible, généré côté serveur et vérifié avant d’exécuter l’action. Sans ce jeton exact, la requête est rejetée, peu importe la présence d’un cookie valide.

À compléter avec l’attribut de cookie SameSite=Strict ou Lax, qui empêche justement le navigateur d’envoyer le cookie de session lors d’une requête initiée depuis un autre site. Les deux mesures se renforcent mutuellement ; aucune des deux ne suffit seule à couvrir tous les cas.

Comment SauronSec la détecte

Chaque formulaire qui modifie un état est passé au crible : présence d’un jeton CSRF valide, attribut SameSite du cookie de session, origine de la requête vérifiée avant de conclure.

Anti-faux-positif assumé : un formulaire de connexion contenant un mot de passe n’a structurellement pas besoin d’un jeton CSRF classique et n’est jamais signalé à tort ; de même, un cookie XSRF-TOKEN lisible en JavaScript par conception (Angular, Django) — son absence de HttpOnly EST le fonctionnement normal attendu, pas une faille à corriger.