CSRF : Comprendre, détecter et se protéger contre la falsification de requête inter-sites

CSRF (Cross-Site Request Forgery, ou " falsification de requête inter-sites ") est une technique permettant à un site malveillant de pousser le navigateur d'un utilisateur authentifié à réaliser une action sur un autre site sans son consentement explicite. L'attaquant n'a pas besoin de connaître le mot de passe de la victime, ni d'intercepter sa session ou d'accéder à son compte : il lui suffit de profiter du fait que le navigateur considère déjà l'utilisateur comme connecté.

CSRF : définition et fonctionnement

Le terme CSRF signifie Cross-Site Request Forgery, soit la " falsification de requête inter-sites ". Le principe : une page ou un lien malveillant initie une requête vers un autre site, et le navigateur y joint automatiquement les données d'authentification (cookies de session, par exemple). Si le serveur ne vérifie pas l'origine de la requête, il peut la prendre pour une action légitime de l'utilisateur.

Ce type d'attaque est particulièrement dangereux pour les opérations qui modifient des données : changements de paramètres de profil, d'adresse e-mail, d'options de compte ou toute action critique. Comprenons pourquoi la CSRF est possible, le rôle des cookies, et comment les jetons CSRF permettent de distinguer une requête authentique d'une requête truquée.

CSRF en termes simples

Une attaque CSRF utilise la situation où l'utilisateur est déjà connecté à un site et où son navigateur conserve la session. Par exemple, si une personne reste connectée à une boutique en ligne ou à une interface d'administration, le navigateur continue de joindre automatiquement les cookies de session à chaque requête.

Si, durant cette période, l'utilisateur visite une page piégée, clique sur un lien malveillant ou charge un élément externe, le navigateur peut envoyer une requête au service où il est déjà authentifié - sans que l'utilisateur ne s'en rende compte.

Le danger survient si le serveur se fie simplement à la présence d'une session valide, sans s'assurer que la requête a été initiée via l'interface du site.

En résumé : l'utilisateur se connecte, obtient une session, puis visite une page externe qui déclenche une requête vers le service cible. Le navigateur joint les cookies de session, et le serveur considère la requête comme légitime.

Que signifie Cross-Site Request Forgery ?

Le terme Cross-Site Request Forgery décrit bien le phénomène : la requête est créée sur un site, mais envoyée vers un autre, au nom d'un utilisateur déjà authentifié.

Il faut distinguer l'attaque CSRF de la vulnérabilité CSRF. Une attaque CSRF est une tentative pour pousser le navigateur à réaliser une action non souhaitée. Une vulnérabilité CSRF est une faille logique de l'application web, qui permet au serveur d'accepter la requête sans vérification supplémentaire.

Le navigateur n'agit pas " mal " : il suit son comportement standard en joignant les cookies liés au domaine, conformément aux réglages de sécurité. La faille est côté application, si celle-ci considère la session comme preuve suffisante de l'intention de l'utilisateur.

La CSRF n'implique donc pas nécessairement un vol de mot de passe ou une compromission de compte : l'attaquant exploite l'authentification existante pour déclencher une action permise.

Comment fonctionne une attaque CSRF : du site malveillant à l'action à l'insu de l'utilisateur

Pourquoi le navigateur envoie-t-il automatiquement les cookies ?

Après authentification, le site crée une session liée au navigateur par un cookie. Lors des requêtes suivantes vers ce domaine, le navigateur joint automatiquement ce cookie, évitant à l'utilisateur de saisir à nouveau ses identifiants à chaque action.

C'est ce comportement qui est exploité par la CSRF : une page externe peut tenter de déclencher une requête vers le site où l'utilisateur est connecté. Si le navigateur joint les cookies de session, le serveur voit une authentification valide et peut accepter la requête.

Le problème : la présence du cookie prouve la session, mais pas la volonté de l'utilisateur d'effectuer l'action. Si l'application ne prévoit pas de vérification supplémentaire, l'attaquant peut profiter de cet écart entre authentification et intention.

Exemple d'attaque CSRF

Imaginons un service où un utilisateur connecté peut modifier les paramètres de son compte. Si le serveur accepte la requête de modification simplement sur la base de la session active, une page externe pourrait tenter de générer la même requête.

L'utilisateur ouvre un site inconnu : en arrière-plan, son navigateur interagit avec le service ciblé. Pour le serveur, la requête semble provenir du client déjà connecté.

L'attaquant n'a pas forcément accès à la réponse du serveur ou au contenu du compte. Le but classique d'une CSRF est de pousser le système à effectuer une action au nom de la victime, non de lire ses données.

Quelles actions sont les plus à risque ?

• Modifications de données personnelles ou de sécurité : e-mail, mot de passe, profil.
• Actions dans une interface d'administration.
• Toute opération qui change l'état de l'application et ne demande pas de confirmation supplémentaire.

Plus un utilisateur a de droits, plus les conséquences peuvent être graves : une attaque CSRF sur un compte administrateur peut être catastrophique.

Les opérations sensibles ne doivent donc pas être acceptées sur la seule base d'une session valide. Le serveur doit s'assurer que la requête provient bien de son interface de confiance.

Jeton CSRF : comment distinguer une vraie requête d'une requête falsifiée

Qu'est-ce qu'un jeton CSRF ?

Un jeton CSRF est une valeur supplémentaire que le serveur attend lors d'une requête sensible. Ce jeton, généré pour l'utilisateur, la session ou un formulaire précis, est inséré dans la page concernée.

Lorsque l'utilisateur soumet un formulaire ou change des paramètres via l'interface du site, le navigateur renvoie le jeton au serveur. Celui-ci vérifie la correspondance avant d'exécuter l'opération.

Résultat : une session active ne suffit plus. Même si le navigateur joint le cookie de session, une requête sans le bon jeton CSRF est rejetée.

Pourquoi l'attaquant ne peut-il pas envoyer le bon jeton ?

Un site externe n'a pas accès au contenu interne d'une page d'un autre domaine. Il peut déclencher une requête, mais ne peut pas lire le jeton CSRF du formulaire cible pour l'insérer dans la requête factice.

C'est la différence fondamentale avec les cookies, qui sont souvent envoyés automatiquement par le navigateur, alors que le jeton CSRF doit être explicitement inclus par l'application.

Si le jeton est imprévisible et correctement vérifié côté serveur, la falsification devient bien plus difficile. Le simple fait d'être connecté ne suffit pas.

Autres mesures de protection contre la CSRF

• SameSite : L'attribut SameSite des cookies limite leur envoi lors de scénarios inter-sites, réduisant ainsi la surface d'attaque.
• Vérification des entêtes Origin ou Referer : Le serveur peut vérifier l'origine des requêtes pour n'accepter que celles provenant de pages de confiance.
• Double confirmation : Pour les actions les plus sensibles, un mot de passe, un code à usage unique ou une confirmation spécifique peuvent être exigés.

Ces mécanismes, combinés, rendent la réussite d'une attaque CSRF bien plus difficile.

CSRF vs XSS : quelles différences ?

CSRF : la confiance du site envers le navigateur

Dans une attaque CSRF, l'attaquant exploite l'authentification existante de l'utilisateur. Le navigateur envoie la requête avec les cookies de session, et le serveur l'accepte comme une action légitime.

Particularité : le code malveillant n'est pas exécuté sur le site cible, mais sur une page externe qui tente de faire agir le navigateur au nom de l'utilisateur.

XSS : la confiance de l'utilisateur envers le site

La faille XSS (Cross-Site Scripting) fonctionne différemment : elle survient quand un site permet l'exécution de scripts JavaScript injectés dans ses propres pages.

Un tel script accède alors aux capacités normalement réservées au site, ce qui peut permettre de modifier le contenu, d'intercepter des actions ou de réaliser des actions au nom de l'utilisateur.

Dans une CSRF, l'attaquant ne lit pas le contenu de la page cible : il cherche à faire envoyer une requête. Dans une XSS, le code malveillant s'exécute dans le contexte du site de confiance, avec un potentiel d'attaque bien plus large.

Pourquoi protéger contre l'un ne suffit pas à protéger contre l'autre ?

Les jetons CSRF protègent contre les requêtes falsifiées mais n'arrêtent pas une attaque XSS. Si un script malveillant s'exécute sur la page, il peut interagir avec l'interface et les mécanismes de sécurité.

L'inverse est vrai : l'échappement des données ou une politique CSP n'empêchent pas une attaque CSRF si les jetons ne sont pas vérifiés.

CSRF et XSS sont donc deux catégories de vulnérabilités web différentes, pouvant avoir des conséquences similaires mais nécessitant des protections distinctes.

Comment protéger un site contre les attaques CSRF ?

Vérifier toutes les requêtes qui modifient les données

La protection CSRF commence par une bonne logique applicative. Les requêtes qui modifient des données ou l'état du système ne doivent jamais être acceptées sur la seule base d'un cookie de session.

Il ne faut jamais utiliser la méthode GET pour une opération de modification. GET doit être réservé à la consultation, tandis que POST, PUT, PATCH ou DELETE, combinés à des vérifications supplémentaires, servent pour les changements.

Le choix du bon verbe HTTP ne suffit pas : si le serveur se fie toujours à la session, la faille reste présente. Les requêtes sensibles doivent contenir un élément de confirmation ou faire l'objet d'une vérification d'origine.

Utiliser des jetons CSRF et les cookies SameSite

La méthode principale de protection consiste à utiliser des jetons CSRF : le serveur génère une valeur imprévisible à attendre lors de chaque requête critique. Un site externe ne peut généralement pas deviner ou récupérer ce jeton, donc même avec une session active, la requête factice échoue.

L'attribut SameSite sur les cookies ajoute une couche : il limite leur envoi lors de requêtes initiées par un autre site, réduisant le risque que le navigateur joigne les données d'authentification à une requête malveillante.

Les jetons CSRF et SameSite ne sont pas redondants, mais complémentaires : le jeton confirme la légitimité de la requête, la politique SameSite limite l'envoi automatique des cookies.

La CSRF n'est qu'une des failles web existantes. Par exemple, l'injection SQL vise non pas le navigateur, mais les requêtes de l'application vers la base de données. Pour aller plus loin, consultez notre guide complet sur l'injection SQL : fonctionnement, risques et protections.

Des vérifications supplémentaires pour les actions critiques

Pour les opérations les plus sensibles, un simple jeton CSRF peut ne pas suffire. La modification du mot de passe, l'ajout d'un moyen de récupération, la gestion des droits ou d'autres actions critiques doivent nécessiter une confirmation d'identité supplémentaire.

Cela peut être une nouvelle saisie de mot de passe, un code temporaire ou une confirmation explicite. Ce mécanisme réduit le risque qu'une action importante soit réalisée par une requête falsifiée.

Le serveur peut aussi analyser les entêtes Origin et Referer pour vérifier la provenance de la requête et rejeter celles en provenance de sources inattendues. Toutefois, ces vérifications doivent compléter - et non remplacer - les protections principales.

Une sécurité efficace repose sur plusieurs niveaux : bons verbes HTTP, jetons CSRF, cookies SameSite, vérification de l'origine des requêtes et confirmation des actions sensibles.

Conclusion

L'attaque CSRF n'exploite pas un mot de passe faible, mais la confiance du site envers un navigateur déjà authentifié. Si le serveur considère qu'une session valide suffit à autoriser n'importe quelle action, une page externe peut tenter de déclencher une requête au nom de l'utilisateur.

La protection principale repose sur les jetons CSRF, qui permettent au serveur de vérifier que la requête provient bien de l'application. S'y ajoutent les cookies SameSite, la vérification des entêtes d'origine, l'emploi des bons verbes HTTP et la confirmation des actions critiques.

Pour le développeur, une règle clé : la présence d'une session valide ne garantit pas que l'utilisateur est bien à l'origine de la requête. Toute opération de modification doit être authentifiée de manière indépendante côté serveur.