Applications, sites et API

Particuliers et entreprises

Falsification de requête intersite

Cross-site request forgery — CSRF

Un site trompe le navigateur pour déclencher une action sur un autre service.

Révision éditoriale : Comprendre : 2 min · Cas technique et détails : 5 min
Je pense être concerné : que faire ?
Illustration pédagogique : falsification de requête intersite.

Comprendre et agir

À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.

Une situation concrète

Une personne est connectée à son espace client. Une autre page tente de lui faire envoyer, sans qu’elle le comprenne, une demande de modification vers cet espace. Si le service se fie uniquement à la présence de la connexion, il peut accepter l’action.

Comment cela fonctionne

Une CSRF fait utiliser au navigateur une connexion déjà ouverte pour transmettre une action non souhaitée. L’attaquant n’a pas forcément besoin de connaître le mot de passe ni de lire la réponse. Le défaut apparaît lorsque le service ne vérifie pas suffisamment que l’action vient de son interface et de l’intention de la personne. La protection doit être intégrée au site.

Comment le piège fonctionne
  1. La session est déjà ouverte

    Le navigateur connaît le service.

  2. Une autre page provoque une action

    La demande emprunte cette session.

  3. Le service l’accepte à tort

    Le service se fie au cookie sans vérifier la provenance de l’action.

Ce que vous pouvez faire

Vos premiers réflexes

Vérifiez les modifications de compte que vous ne reconnaissez pas et signalez-les au service. La protection contre ce mécanisme doit être intégrée par son développeur.

Si vous êtes responsable du service ou de l’organisation

Développeurs : protégez toutes les routes qui modifient des données avec les contrôles adaptés au mode d’authentification. Une consultation en GET ne doit pas déclencher une modification.

Le détail qui change toutUne idée reçue à corriger

Une CSRF peut agir sans voler le cookie de session.

À vous de décider

Votre mot de passe n’a pas été volé. Une autre page peut-elle tout de même déclencher une action sur un site vulnérable ?

Choisissez votre réponse et expliquez pourquoi avant de lire la correction.

Voir la réponse expliquée

Oui. Le navigateur peut joindre les cookies d’une session déjà ouverte. Le service doit vérifier la provenance de l’action, au-delà de la seule présence de la session.

Analyser un cas technique

Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.

Étude de cas fictive

Le navigateur envoie une action que l’utilisateur n’a pas demandée

Une CSRF exploite une session déjà ouverte. Une autre page provoque l’envoi d’une requête vers le service ; le navigateur peut y joindre les cookies du titulaire. Si le serveur se contente de reconnaître cette session, il risque d’accepter une action que la personne n’a jamais choisie.

Le contrôle doit porter sur les opérations qui changent un état : coordonnées, mot de passe, commande ou virement. Un jeton anti-CSRF lié à la session permet de vérifier que la requête provient du parcours attendu. Il doit être vérifié côté serveur. Le contrôle de l’origine et les attributs SameSite des cookies complètent cette protection selon le fonctionnement de l’application.

Un refus sur un formulaire ne suffit pas si une route d’API ou une ancienne version accepte la même opération sans contrôle. Vérifier aussi les méthodes HTTP employées : une simple lecture en GET ne devrait pas modifier de données.

Pour l’enquête, distinguer la présence du cookie et l’acceptation du contrôle anti-CSRF. Un cookie valide identifie une session ; il ne démontre pas l’intention de son utilisateur. Si une XSS existe sur la même origine, elle peut en outre utiliser le parcours légitime et ses jetons.

Le déroulement en schéma

Qui échange avec quiLisez les échanges de haut en bas. Le point marque le départ et la flèche l’arrivée. Les vérifications après correction ne sont pas la suite de l’attaque.

Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.

Étape
Page externeOrigine non fiable
NavigateurCookies applicables
Serveur compteValidation CSRF
Stockage métierMutation persistante
  1. Action

    Déclenchement d’une requête

    Page externe vers Navigateur

  2. Action

    POST + cookie si applicable

    Navigateur vers Serveur compte

    Trace Origin / SameSite

  3. Action

    Avant correction : écriture sans contrôle CSRF

    Serveur compte vers Stockage métier

    Trace mutation=committed

  4. Réponse

    Réponse non lisible par la page externe

    Serveur compte vers Navigateur

  5. Action

    Après correction : même requête sans jeton

    Navigateur vers Serveur compte

  6. Refus / blocage

    Refus avant écriture

    Serveur compte vers Navigateur

    Trace csrf=rejected

  7. Action

    Seule une décision validée autorise la mutation

    Serveur compte vers Stockage métier

Comment repérer cette attaque

Indices à rechercher

  • Une action survient après la consultation d’une page sans lien apparent.
  • Une route modifiant des données accepte des demandes sans contrôle d’origine ni jeton adapté.
  • Des requêtes sensibles arrivent depuis un contexte de navigation inattendu.

Examiner les modifications de compte ou de données non reconnues, en particulier lorsque le contrôle anti-CSRF a échoué ou que sa décision manque dans les journaux.

Éléments à croiser

Relier la requête à la modification réellement enregistrée sur le compte. Une réponse HTTP 200 peut afficher un message d’erreur : seule la trace de décision ou l’historique métier établit la mutation.

Limites de l’interprétation

Un Origin absent ne prouve pas une attaque. Le contexte de navigation, la méthode et les protections appliquées doivent être connus ; ne pas confondre absence de jeton visible et absence de toute protection CSRF.

Comment réagir

Protéger toutes les routes qui modifient un état, y compris les anciennes API. Corriger les opérations déclenchées par GET et vérifier les cookies. Retrouver les actions réalisées avec les sessions concernées et annuler celles qui peuvent l’être. Fermer une session n’annule pas une modification déjà enregistrée.

Vérifier la correction

Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.

  1. Une opération sensible doit être refusée lorsque son jeton est absent, incorrect ou lié à une autre session.
  2. Les routes alternatives et les API doivent appliquer le contrôle prévu pour leur mode d’authentification.
  3. Le parcours légitime doit continuer à fonctionner avec la politique de cookies retenue.

À vous de raisonner

Le formulaire refuse un jeton absent, mais une ancienne route permet la même modification avec le seul cookie. La protection est-elle complète ?

Formulez votre décision et l’élément qui la justifie avant d’ouvrir la correction.

Comparer avec le raisonnement expliqué

Non : la route alternative reste un chemin d’accès à la même opération. Vérifiez côté serveur tous les parcours qui changent cet état, selon leur mode d’authentification. Le cookie valide identifie une session, pas l’intention de son titulaire.

Consulter les détails techniques

Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.

Lire les extraits commentés — reconstitution fictive

Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-les dans les extraits.

csrf_checked=false
Annotation fictive ajoutée à la requête pour expliquer le cas ; ce n’est pas un en-tête HTTP fourni par le navigateur.
mutation=committed
Résultat supposé du journal métier : le changement a été enregistré, pas seulement demandé.

Requête reçue et décision du serveur

HTTP

Message pédagogique, cookie remplacé par un marqueur non utilisable.

POST /account/email HTTP/1.1
Host: compte.example.test
Origin: https://contenu.example.org
Content-Type: application/x-www-form-urlencoded
Cookie: session=DEMO_NON_VALIDE

email=nouvelle%40example.test

# Audit synthétique avant correction :
# session=s17 authenticated=true csrf_checked=false mutation=committed
# Après correction :
# session=s17 authenticated=true csrf_checked=true result=rejected
Préparer une collecte dans votre environnement

Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des secrets.

  1. Chrome DevTools — panneau Network du navigateur

    Où les trouver
    Dans une capture déjà conservée, ou sur une reproduction autorisée en environnement de test : ouvrir Network et conserver la navigation avec Preserve log. Examiner Headers et Initiator.
    Quoi relever
    Examiner la méthode, l’URL et l’en-tête Origin de la requête, ainsi que la réponse. Ne pas copier les valeurs de cookies ; leur présence montre seulement que le navigateur les a joints.
    Accès et prérequis
    La capture doit être active pendant l’observation : elle ne reconstitue pas le passé. Un export HAR peut contenir des données privées, même après retrait des en-têtes sensibles ; le nettoyer avant partage.
    Documentation : Chrome DevTools — panneau Network du navigateur

  2. Service concerné — audit et historique à vérifier

    Où les trouver
    Dans l’outil d’administration ou les journaux du service concerné. Demander à son mainteneur où sont enregistrées les décisions d’autorisation et les opérations métier.
    Quoi relever
    Chercher la décision de vérification CSRF et l’écriture métier : compte concerné, ancienne/nouvelle valeur non sensible, résultat et identifiant de requête. Ces éléments doivent être audités par le service.
    Accès et prérequis
    Il n’existe ni fichier ni vocabulaire universels. Les champs proposés ici doivent être instrumentés s’ils manquent ; ne pas enregistrer mots de passe, jetons ou contenu privé intégral.
    Documentation : Service concerné — audit et historique à vérifier

Si vous pensez être concerné

Si vous utilisez le service

Vérifiez les modifications de compte que vous ne reconnaissez pas et signalez-les au service. La protection contre ce mécanisme doit être intégrée par son développeur.

Pour l’équipe qui exploite le service

  1. Signalez l’action non reconnue au service et faites-la annuler si possible.
  2. Examinez les autres opérations de la session.
  3. Corrigez les contrôles de chaque route concernée, y compris les anciennes interfaces.

Pour qualifier votre situation et être orienté : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.

Sources et repères pour approfondir

Pour relier les mécanismes

Injection de scripts dans une page ↗Vol et détournement de session ↗Détournement de clic ↗Toutes les fiches ECRAN →