Aller au contenu
TortueTech
RubriquesRéférentiels & catalogues

CWE-352 : falsification de requête inter-sites (CSRF)

CWE-352 : falsification de requête inter-sites (CSRF)

Section intitulée « CWE-352 : falsification de requête inter-sites (CSRF) »

Troisième du CWE Top 25 2025, ce qui surprend : beaucoup de gens considèrent le CSRF comme un problème réglé par les navigateurs vers 2020. Le classement dit le contraire, et le catalogue explique pourquoi. Le libellé officiel est Cross-Site Request Forgery (CSRF), « falsification de requête inter-sites », et le MITRE enregistre trois autres appellations tombées en désuétude : session riding, cross site reference forgery, XSRF.

→ Lire l’explication complète de la marmotte

Ce que la classe recouvre exactement

Section intitulée « Ce que la classe recouvre exactement »

La définition du MITRE est d’une précision inhabituelle : l’application web ne vérifie pas, ou ne peut pas vérifier suffisamment, si une requête a été fournie intentionnellement par l’utilisateur qui l’a envoyée.

Le « ne peut pas » mérite qu’on s’y arrête. Il reconnaît que le défaut n’est pas toujours une négligence : le protocole HTTP, tel qu’il est, ne transporte aucune preuve de l’intention. Le navigateur joint les cookies de session à toute requête vers le domaine concerné, quelle que soit la page qui l’a déclenchée. Du point de vue du serveur, une requête de virement émise par son propre formulaire et une requête identique déclenchée par une page étrangère sont le même objet. Tout le travail de défense consiste à ajouter au protocole ce qu’il ne fournit pas : une preuve que la requête vient bien de l’interface prévue.

La classe couvre donc toute action exécutée au nom d’un utilisateur authentifié, à son insu, quand l’application n’a aucun moyen de distinguer l’intention. Elle ne couvre pas le vol de session, qui relève d’autres entrées, ni l’absence d’authentification, ni la lecture de données : un CSRF fait agir, il ne fait pas lire, puisque la réponse part dans le navigateur de la victime et reste inaccessible à l’attaquant par construction.

Sa place dans l’arbre : une faiblesse composée

Section intitulée « Sa place dans l’arbre : une faiblesse composée »

CWE-352 est l’un des sept composés (compound) du catalogue, catégorie rare et éclairante : une faiblesse composée n’existe que par la conjonction de plusieurs autres. Le MITRE liste quatre conditions nécessaires, avec la relation Requires :

  • CWE-346, erreur de validation d’origine : l’application ne vérifie pas d’où vient la requête ;
  • CWE-441, intermédiaire involontaire, le « député confus » : le navigateur de la victime agit comme relais de confiance ;
  • CWE-642, contrôle externe d’une donnée d’état critique : la session vit dans un cookie que le navigateur joint automatiquement ;
  • CWE-613, expiration de session insuffisante : plus la session dure, plus la fenêtre d’attaque est large.

Retirez l’une des quatre et l’attaque tombe. C’est ce qui explique l’efficacité du mécanisme SameSite : il s’attaque à la troisième condition, sans toucher aux autres.

Le parent est la classe CWE-345, vérification insuffisante de l’authenticité des données : la même famille que les webhooks non signés ou les mises à jour non vérifiées. Le CSRF n’a pas d’enfant : la finesse supplémentaire se décrit par les conditions, non par des variantes.

Enfin, CWE-79 est un pair, et leur relation est à sens unique : un cross-site scripting permet de lire le jeton anti-CSRF avant de s’en servir, donc annule la défense. Une protection anti-CSRF n’a de valeur que sur une application sans XSS, ce qui est à retenir avant de hiérarchiser deux tickets.

Pourquoi elle est encore au rang 3

Section intitulée « Pourquoi elle est encore au rang 3 »

Trois raisons, et la première est un effet de méthode.

Les protections par défaut du navigateur ne couvrent pas tout. L’attribut SameSite, désormais appliqué par défaut en mode Lax par les principaux navigateurs, bloque l’envoi du cookie sur les requêtes inter-sites, mais pas sur toutes : la navigation de haut niveau en GET reste autorisée, les API qui s’authentifient autrement que par cookie ne sont pas concernées, et toute application qui remet SameSite=None pour faire fonctionner une intégration tierce rouvre la porte en grand. La défense est devenue la règle sans devenir une garantie.

Les produits concernés sont innombrables et anciens. Routeurs, caméras, imprimantes, interfaces d’administration d’appareils, greffons de systèmes de publication : tout ce qui expose un formulaire d’administration sans jeton anti-CSRF alimente le classement, et ces produits se corrigent au rythme de leurs micrologiciels, c’est-à-dire lentement.

La détection est facile en revue de code. L’absence de jeton se repère sans exécuter l’application, ce qui gonfle naturellement le nombre de vulnérabilités publiées. On retrouve le biais général du classement : il mesure ce qui se signale bien.

Le mécanisme, et où le site le traite

Section intitulée « Le mécanisme, et où le site le traite »

Le site n’a pas de page dédiée au CSRF, mais ses deux pièces maîtresses y sont traitées. Les attributs du cookie de session décrivent SameSite, ce qu’il bloque et ce qu’il laisse passer, ainsi que les conséquences de None ; la politique de même origine explique ce que le navigateur cloisonne, et donc pourquoi l’attaquant peut émettre une requête sans pouvoir lire la réponse : la limite qui définit la portée exacte de cette faiblesse.

Le mécanisme, en deux phrases qu’il faut bien poser puisqu’aucune page ne le fait : l’attaquant fait charger par le navigateur de la victime une ressource qui déclenche une requête vers l’application cible (formulaire soumis automatiquement, image dont l’adresse est en réalité une action). Le navigateur joint la session, l’application exécute. La défense consiste à exiger dans chaque requête modifiante une valeur imprévisible, liée à la session, que seule l’interface légitime connaît, et à refuser la requête en son absence.

Deux renvois pour les cas particuliers : la fixation de session montre une autre façon d’abuser du même cookie, et les pièges d’OAuth 2.1 décrivent le paramètre state, qui est un jeton anti-CSRF appliqué au flux d’autorisation, même faiblesse, autre protocole.

Ce qu’une équipe en fait

Section intitulée « Ce qu’une équipe en fait »

Trois contrôles, qui se cumulent plutôt qu’ils ne se remplacent.

Un jeton anti-CSRF fourni par le cadre applicatif, activé globalement et non formulaire par formulaire. Tous les cadres sérieux en proposent un ; la faiblesse apparaît presque toujours là où quelqu’un l’a désactivé pour faire passer un test.

SameSite=Lax ou Strict sur les cookies de session, avec l’interdiction de revenir à None sans une justification écrite et une compensation explicite.

La vérification de l’origine sur les requêtes modifiantes, qui rattrape les cas où le jeton manque. Et, pour les actions irréversibles, une réauthentification : c’est le seul contrôle qui résiste même quand les trois autres ont été contournés.

Sources

Section intitulée « Sources »

🐝 Ce qui arrive si on s’en passe

Section intitulée « 🐝 Ce qui arrive si on s’en passe »

Une équipe qui croit le CSRF réglé par le navigateur désactive la protection de son cadre applicatif pour débloquer une intégration, et ne la remet jamais. L’application continue de fonctionner parfaitement, les tests passent, et le défaut ne se manifeste que le jour où quelqu’un s’en sert. Le dégât est alors d’une nature particulière : les journaux ne montrent aucune anomalie, puisque chaque action a bien été émise par le navigateur d’un utilisateur légitime, authentifié, depuis son adresse habituelle. L’enquête conclut à une erreur de l’utilisateur, qui jure n’avoir rien fait, et c’est vrai. Les actions administratives sont les plus coûteuses : création de compte, changement d’adresse de courriel, modification d’un droit, autant d’opérations qui transforment une page piégée en accès permanent, sans qu’aucun mot de passe n’ait été volé.

🦫 Explication de la marmotte 🍫

Section intitulée « 🦫 Explication de la marmotte 🍫 »

Quand on se connecte à un site, le navigateur reçoit un petit jeton appelé cookie, qu’il renvoie automatiquement à chaque visite suivante. C’est ce qui évite de retaper son mot de passe à chaque page. Mais le navigateur renvoie ce cookie à chaque fois qu’une requête part vers ce site, même lorsque la requête a été déclenchée par une autre page.

Un attaquant peut donc préparer une page ordinaire (un article, une image, un faux formulaire de participation), qui déclenche en arrière-plan une action sur un site où la victime est connectée : changer son adresse de courriel, valider un virement, créer un compte administrateur. Le site reçoit une demande accompagnée du bon cookie et l’exécute. Il n’a aucun moyen de savoir que l’utilisateur ne voulait pas cette action : c’est bien son navigateur qui l’a envoyée.

Ce défaut s’appelle CWE-352, ou « falsification de requête inter-sites ». Sa particularité est de ne pas reposer sur un vol : l’attaquant n’obtient ni mot de passe ni cookie, et ne voit même pas le résultat de l’action. Il se contente de faire agir le navigateur de quelqu’un d’autre.

La protection consiste à ajouter dans chaque formulaire une valeur secrète et imprévisible, que le site vérifie à réception : une page étrangère ne peut pas la deviner. Les navigateurs modernes aident aussi, en cessant d’envoyer les cookies sur les requêtes déclenchées depuis un autre site : c’est le réglage appelé SameSite. Ces deux défenses ont fait reculer le problème sans le faire disparaître, parce qu’il suffit qu’un développeur désactive l’une pour une raison technique, ou qu’un appareil ancien n’en ait jamais entendu parler, pour qu’il revienne.

À lire aussi

Pages voisines

La citent

CWE-352 : falsification de requête inter-sites (CSRF)

Elle cite

: les deux pages se citent l’une l’autre.