Applications, sites et API

Particuliers et entreprises

Falsification de requête intersite

Cross-site request forgery — CSRF

Une page pousse votre navigateur à agir sur un autre service où vous êtes connecté.

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

Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.

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 attaque CSRF fait envoyer à votre navigateur une action que vous n’avez pas souhaitée, en profitant d’une connexion déjà ouverte sur un autre service. L’attaquant n’a pas forcément besoin de votre mot de passe, ni de lire la réponse. Le service vulnérable ne vérifie pas assez que l’action vient de son interface et correspond à votre intention. C’est au site d’intégrer cette protection.

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

Si vous développez le service, protégez chaque route qui modifie des données avec les contrôles adaptés à son authentification. Une demande de consultation en GET ne doit pas modifier les données.

Un point à vérifierUne 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 ?

Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.

Voir la réponse expliquée

Oui. Votre navigateur peut envoyer les cookies d’une session déjà ouverte. Le service doit donc vérifier d’où vient l’action, en plus de reconnaître la session.

Analyser un cas technique

Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».

Étude de cas fictive

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

Une personne est déjà connectée à un service. Une autre page fait envoyer une requête à ce service par son navigateur, qui peut y joindre ses cookies. Si le serveur vérifie seulement que la session existe, il peut accepter une action que la personne n’a jamais choisie. C’est le principe d’une CSRF.

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.

Quelles informations comparer

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.

Ce que ces indices ne permettent pas de conclure

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

L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.

  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 ?

Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez 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

Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.

Lire les extraits commentés (reconstitution fictive)

Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-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

Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les 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 comprendre votre situation et trouver de l’aide : 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

Sur des sujets proches

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