Le CSRF : l'action forcée à votre insu

L'attaquant commence par repérer une requête qui modifie quelque chose sur un service, puis il fabrique une adresse ou un script qui la reproduit avec ses propres valeurs. OWASP prend l'exemple d'une banque fictive : la requête légitime vire 100 dollars à un bénéficiaire, et l'attaquant remplace le bénéficiaire par lui-même en augmentant le montant¹.

Reste à faire charger cette requête par la victime pendant qu'elle est connectée. Deux méthodes sont citées : un e-mail non sollicité au contenu HTML, ou un piège placé sur des pages que la victime est susceptible de visiter pendant qu'elle utilise son service en ligne¹.

L'attaque peut aussi être stockée sur le site vulnérable lui-même, par exemple dans un champ qui accepte du HTML. Elle devient alors plus probable : la victime consulte plus volontiers une page du site qu'une page quelconque d'Internet, et elle y est forcément déjà connectée¹.

Souvent, rien. Le lien piégé peut être déguisé en lien ordinaire, avec un texte du genre « voir mes photos ». Il peut aussi prendre la forme d'une fausse image de taille nulle : si elle figure dans un e-mail, la victime ne voit rien, mais le navigateur envoie quand même la requête, sans aucun signe visuel que l'opération a eu lieu¹.

Illustration neutralisée, pas une adresse réelle.
Lien déguisé : texte affiché « Voir mes photos », adresse cachée
hxxp://banque[.]exemple[.]invalid/virement?dest=[compte de l'attaquant]&montant=[élevé]
Variante : image invisible dans un e-mail, chargée sans clic.

Si le service attend une requête de type POST, l'attaquant peut héberger sur son site un formulaire aux champs cachés. La victime croit qu'il fait autre chose et clique, ou bien un script l'envoie automatiquement au chargement de la page¹. Dans les deux cas, la page affichée est banale et l'action se déroule ailleurs.

Le mécanisme tient à un comportement normal des navigateurs. Ils enregistrent les cookies émis par une application, dont les cookies de session des utilisateurs authentifiés, et ils envoient tous les cookies d'un domaine à chaque requête, quelle que soit la façon dont cette requête est née dans le navigateur². Les cookies ne sont pas seuls en cause : les authentifications de type Basic et Digest sont aussi vulnérables, car le navigateur renvoie automatiquement les identifiants jusqu'à la fin de la session².

Plusieurs idées de défense ne fonctionnent pas, selon OWASP¹ :

• un cookie secret, puisque tous les cookies sont envoyés avec chaque requête ;
• n'accepter que les requêtes POST, puisqu'un formulaire caché suffit à en forger une ;
• les transactions en plusieurs étapes, tant que l'attaquant peut prévoir chaque étape ;
• la seule vérification de l'en-tête Referer, car il peut être falsifié, et il est parfois absent pour des raisons de confidentialité.

Les protections recommandées, côté application, sont les suivantes.

• Vérifier d'abord si le cadriciel (framework) offre déjà une protection CSRF, et l'utiliser. À défaut, ajouter des jetons anti-CSRF à toutes les requêtes qui modifient l'état et les valider côté serveur³. Sans jeton, l'attaquant ne peut pas fabriquer de requête valide³.
• Pour les logiciels sans état, utiliser un cookie en double soumission, de préférence signé³.
• Poser l'attribut SameSite sur les cookies de session³. Avec la valeur strict, le navigateur n'envoie pas le cookie sur les requêtes inter-sites, même en suivant un lien ordinaire. Avec lax, il l'envoie pour un lien suivi depuis un autre site mais le retient sur les méthodes exposées au CSRF comme POST⁴. Avec none, aucune protection n'est offerte⁴.
• Contrôler l'origine avec les en-têtes standards, notamment Sec-Fetch-Site, pris en charge par tous les grands navigateurs depuis mars 2023³.
• Ne pas utiliser de requêtes GET pour des opérations qui modifient l'état³.

Ces mesures ont des limites. SameSite=Lax laisse passer les requêtes GET de navigation de premier niveau : un point d'accès qui modifie l'état par GET reste vulnérable². Les anciens navigateurs peuvent ne pas appliquer SameSite². Et une faille XSS peut contourner toutes les protections anti-CSRF ; le ver Samy, par exemple, a utilisé un XMLHttpRequest pour obtenir le jeton CSRF et forger des requêtes¹³. Le comportement par défaut de SameSite varie : en décembre 2024, lax était la valeur par défaut de Chrome, Edge et Opera, mais d'aucune version de Firefox ni de Safari, d'où le conseil de la fixer explicitement⁴.

2008 : l'exploit uTorrent

OWASP cite, comme exemple réel d'attaque CSRF contre une application fonctionnant par requêtes GET, un exploit visant uTorrent datant de 2008. Il a été utilisé à grande échelle pour télécharger des logiciels malveillants¹. La source n'en dit pas plus : ni le nombre de victimes, ni le mode de diffusion.

Failles cataloguées par le CWE (identifiants de 2004 à 2009)

Le CWE-352 donne une liste choisie d'exemples observés, qui n'est pas exhaustive⁵. Plusieurs reposent sur une simple URL dans une balise img : CVE-2004-1703 et CVE-2004-1995 permettent d'ajouter des comptes utilisateurs, CVE-2004-1842 de gagner des privilèges d'administrateur⁵. D'autres touchent la gestion elle-même : CVE-2009-3520 permet de modifier le mot de passe de l'administrateur, et CVE-2009-3759 de changer des mots de passe ou d'arrêter une machine virtuelle depuis une interface web⁵.