Le Cross-Site Request Forgery (CSRF) : comprendre et contrer le piège de la session compromise
Cet article fait partie de la série Les types de failles informatiques : classement par sévérité et guide complet.
Niveau de sévérité dans cette série : Faible à Moyenne. Classification indicative (détourne l’authentification déjà active d’une victime pour agir en son nom) ; la gravité réelle d’une faille dépend toujours du contexte précis et, idéalement, de son score CVSS.
Imaginez qu’un individu malveillant vous tende un piège en vous incitant à cliquer sur une image anodine sur un forum, provoquant à votre insu un virement bancaire ou la modification de votre mot de passe sur un site où vous étiez connecté. C’est le principe fondamental du Cross-Site Request Forgery (CSRF), parfois appelé XSRF ou « chevauchement de session » (session riding). Cette vulnérabilité web tire parti d’un comportement par défaut du navigateur Internet : l’envoi automatique des identifiants de session lors de toute requête vers un domaine cible.
Origine
Le concept théorique qui sous-tend le CSRF remonte aux travaux de Norm Hardy en 1988 sur le problème du « député confus » (confused deputy problem), une situation où un programme est trompé pour utiliser ses privilèges au profit d’un tiers. C’est au début des années 2000 que la vulnérabilité est formellement identifiée dans l’univers web, notamment en l’an 2000 avec la découverte d’une faille affectant le serveur d’applications Python Zope.
Le terme « Cross-Site Request Forgery » est forgé en juin 2001 par le chercheur en sécurité Peter Watkins sur la liste de diffusion Bugtraq. Très rapidement, la communauté informatique réalise que la quasi-totalité des applications web s’appuyant uniquement sur des cookies pour authentifier les requêtes est vulnérable. Longtemps surnommé le « géant endormi » de la sécurité web par les experts, le CSRF fait son entrée dans le classement OWASP Top 10 dès 2007, attirant l’attention des développeurs du monde entier sur la gestion des sessions HTTP.
Définition
Techniquement, le CSRF se produit lorsqu’une application web traite des requêtes entrantes sans vérifier si elles ont été délibérément initiées par l’utilisateur. Lorsqu’un utilisateur s’authentifie sur un site web (par exemple, banque.example.com), le serveur lui attribue un cookie HTTP de session. Tant que ce cookie est valide, le navigateur l’annexe automatiquement à chaque requête envoyée vers banque.example.com, peu importe la page d’origine qui a provoqué la requête.
Il ne faut pas confondre le CSRF avec le Cross-Site Scripting (XSS). La différence essentielle réside dans la méthode et la cible :
- Dans une attaque XSS : l’attaquant parvient à injecter et exécuter du code JavaScript malveillant au sein même du site cible. Ce code peut lire les cookies, intercepter les frappes au clavier ou voler des jetons d’accès.
- Dans une attaque CSRF : l’attaquant n’injecte aucun code dans le site cible. Il abuse de la confiance que le site accorde au navigateur de la victime. L’attaquant forge une requête HTTP depuis un site tiers (
site-malveillant.example) et laisse le navigateur de la victime transmettre automatiquement les cookies d’authentification vers la cible.
Dans notre série sur les failles informatiques, le CSRF est classé à un niveau de sévérité Faible à Moyenne (généralement évalué entre 3.0 et 6.5 sur l’échelle CVSS). Cette classification s’explique par le fait que l’attaque ne permet pas directement à l’attaquant de lire la réponse du serveur (en raison de la politique de même origine ou Same-Origin Policy) ni d’exécuter du code arbitraire sur le serveur. Elle nécessite obligatoirement l’interaction d’un utilisateur légitime disposant d’une session active au moment précis de l’attaque.
Exemples réels
Le CSRF a touché plusieurs plateformes majeures au cours de l’histoire du Web, démontrant la portée concrète de ce type de faille.
La vulnérabilité massive sur YouTube (2008)
En 2008, le chercheur en sécurité Petko D. Petkov (alias pdp) découvre que la plateforme YouTube est vulnérable au CSRF sur presque toutes les actions d’administration de compte. À cette époque, un simple clic sur un lien hébergé sur un site externe permettait à un attaquant de forcer un utilisateur connecté à modifier ses préférences de profil, ajouter des canaux en favoris, envoyer des messages privés ou laisser des commentaires à son insu. YouTube a corrigé cette faille en intégrant des jetons de validation uniques sur l’ensemble de ses formulaires.
Détournement des routeurs et modems grand public
Une application fréquente du CSRF concerne les interfaces d’administration web des routeurs domestiques (Netgear, Linksys, TP-Link, D-Link). Les utilisateurs se connectent fréquemment à l’interface locale de leur routeur (par exemple à l’adresse 192.168.1.1) et oublient de se déconnecter. Un site malveillant consulté en parallèle peut envoyer une requête CSRF en arrière-plan ciblant cette adresse IP privée. Par exemple, la vulnérabilité référencée sous le code CVE-2018-25321 sur certains routeurs TP-Link permettait à un attaquant de modifier à distance la configuration réseau et les règles de sécurité Wi-Fi sans aucune authentification supplémentaire.
Dans d’autres scénarios de piratage de routeurs, les requêtes forgées modifient les serveurs DNS attribués au boîtier réseau (DNS Hijacking). Dès lors, l’ensemble du trafic Internet du domicile est redirigé vers des serveurs contrôlés par l’attaquant, facilitant des attaques d’hameçonnage indétectables.
Comment s’en protéger
La protection contre les attaques CSRF repose sur l’adoption de bonnes pratiques d’architecture logicielle et la configuration adéquate des en-têtes HTTP.
- Mise en place de jetons anti-CSRF (Pattern Token Synchroniseur) : C’est la défense la plus efficace. Pour chaque formulaire ou action modifiant un état (POST, PUT, DELETE), le serveur génère un jeton cryptographique imprévisible, unique et lié à la session de l’utilisateur. Le serveur valide ce jeton lors de la réception de la requête. Un site tiers ne pouvant pas deviner ou lire ce jeton, la requête forgée est rejetée.
- Utilisation de l’attribut de cookie
SameSite: Défini dans les normes du NIST et du W3C, l’attributSameSite=LaxouSameSite=Strictindique au navigateur de ne pas joindre le cookie de session lors des requêtes intersites ascendantes. C’est aujourd’hui la protection par défaut dans la plupart des navigateurs modernes. - Vérification des en-têtes HTTP
OriginetReferer: Le serveur web doit vérifier systématiquement l’en-tête pour s’assurer que la requête provient bien d’un domaine autorisé. - Réauthentification pour les actions critiques : Pour des opérations sensibles comme un changement de mot de passe, la modification d’une adresse email ou un transfert de fonds, exigez la re-saisie du mot de passe actuel ou une confirmation par double facteur (2FA).
derivative work: TheLittleMachineForYou (talk) (CC BY-SA 4.0), via Wikimedia Commons.)
Avez-vous déjà audité vos applications web pour vérifier la présence systématique de jetons anti-CSRF et de cookies SameSite ?
Pour aller plus loin
Liens affiliés Amazon : en tant que Partenaire Amazon, ce site perçoit une commission sur les achats éligibles réalisés via ces liens, sans coût supplémentaire pour vous.
Un ouvrage complet détaillant le fonctionnement des vulnérabilités web courantes, dont le CSRF, et les mécanismes de remédiation.
Un guide concret pour appréhender la sécurité sous l’angle de l’attaquant et mettre en place des contre-mesures adaptées.
Une approche méthodique de la cybersécurité des applications web destinée aux développeurs et administrateurs.
Voir aussi
- Zero-Day : la faille que personne ne voit venir (Critique)
- L’Exécution de Code à Distance (RCE) : Comprendre, Prévenir et Contrôler la Faille Ultime (Critique)
- L’Élévation de Privilèges (Privilege Escalation) : Comprendre et Prévenir la Prise de Contrôle Absolue (Élevée)
- Le Rançongiciel (Ransomware) : Anatomie, Histoire et Stratégies de Protection (Élevée à Critique)
- Le Débordement de Tampon (Buffer Overflow) : Comprendre la Faille Légendaire de la Cybersécurité (Élevée)
- L’Injection SQL (SQLi) : fonctionnement, failles historiques et bonnes pratiques de protection (Élevée)
- L’Attaque de l’Homme du Milieu (Man-in-the-Middle) : comprendre et contrer les interceptions de trafic (Moyenne)
- Le Cross-Site Scripting (XSS) : Comprendre, détecter et contrer la faille web omniprésente (Moyenne)
- L’Ingénierie Sociale et le Phishing : Anatomie de la Première Porte d’Entrée des Cyberattaques (Variable (vecteur d’entrée n°1))
- Toutes les failles informatiques classées par sévérité
