Cross-Site Request Forgery : comment fonctionne cette menace web ?

Cross-Site Request Forgery : comment fonctionne cette menace web ?

Sur internet, de nombreuses interactions paraissent anodines : cliquer sur un bouton, modifier un profil, ou valider un formulaire. Pourtant, derrière ces actions simples, se cachent parfois des tentatives de manipulation invisibles. L’une d’elles, souvent méconnue du grand public, s’appelle le Cross-Site Request Forgery, ou CSRF. Elle exploite la confiance que les sites accordent à leurs utilisateurs authentifiés pour exécuter des requêtes à leur insu.

Le CSRF est une technique utilisée pour piéger un internaute connecté à un site sécurisé, en l’incitant à envoyer des commandes malveillantes, souvent sans qu’il s’en aperçoive. Cette attaque s’insère dans les échanges classiques entre un navigateur et un serveur, ce qui la rend particulièrement discrète. C’est pourquoi elle fait l’objet d’une surveillance constante de la part des développeurs et des responsables de la sécurité informatique.

CSRF : pourquoi l’attaque est souvent indétectable ? 

Le Cross-Site Request Forgery repose sur une idée simple mais redoutable : un site malveillant tente d’exploiter l’identité déjà authentifiée d’un internaute sur un autre site. En d’autres termes, l’utilisateur est connecté à une plateforme (comme une banque ou un réseau social), et pendant ce temps, un site tiers essaie d’exécuter une commande à sa place, à son insu.

Prenons un exemple concret : vous êtes connecté à votre espace client sur un site de commerce en ligne. Vous ouvrez en parallèle un autre site, qui contient un script malveillant. Ce script peut envoyer, à votre insu, une requête vers le premier site — comme une commande de produit ou une modification d’adresse — en se faisant passer pour vous, grâce à votre session encore active.

À lire  Fuite de données chez BNP Paribas Personal Finance : comment protéger vos informations personnelles

Ce type d’attaque fonctionne sans voler vos identifiants, ce qui la rend plus difficile à détecter. Il ne s’agit pas d’un piratage classique, mais d’un abus de confiance dans la session utilisateur.

Les conditions favorables à l’attaque CSRF

Pour qu’une attaque CSRF réussisse, la victime doit être déjà connectée à la plateforme visée. C’est cette connexion ouverte qui permet au site malveillant de profiter de l’identification automatique du navigateur.

Absence de vérification dans les requêtes

Les requêtes sensibles (comme le transfert d’argent ou le changement d’e-mail) doivent être correctement protégées. Si le serveur ne vérifie pas l’origine de la requête, alors même une action envoyée depuis un autre domaine peut être validée.

Chargement automatique via HTML ou JavaScript

Les attaques CSRF utilisent souvent des requêtes POST ou GET déguisées, intégrées dans des balises HTML ou des scripts JavaScript. Par exemple, un simple lien caché ou une image invisible peut déclencher une action, sans interaction directe de l’utilisateur.

Exemples d’actions ciblées par le CSRF

  • Changement d’adresse e-mail
  • Modification d’un mot de passe
  • Transfert de fonds
  • Publication non désirée sur un réseau social
  • Ajout ou suppression d’éléments dans un panier

Toutes ces actions partagent un point commun : elles s’appuient sur la session authentifiée de l’utilisateur. Si ces actions ne sont pas sécurisées par des mécanismes de vérification, elles deviennent vulnérables.

Les moyens de prévention contre le CSRF

La méthode la plus répandue pour contrer cette menace consiste à insérer un jeton unique et temporaire dans chaque formulaire sensible. Ce code, généré par le serveur, doit être renvoyé à l’identique par le navigateur lors de la validation. Si le jeton est absent ou incorrect, la requête est automatiquement rejetée.

À lire  Phishing bancaire : comment reconnaître les faux SMS de votre banque ?

Cela permet de vérifier que la demande a bien été formulée depuis le site légitime, et non depuis un autre domaine.

Contrôle du référent HTTP

Certaines applications vérifient également l’origine de la requête via l’en-tête Referer ou Origin. Cela permet de s’assurer que l’action a été déclenchée depuis une page autorisée du même site.

Protection des actions sensibles

Il est aussi recommandé de demander une confirmation explicite pour les opérations critiques (modification de mot de passe, suppression de compte, etc.). Cela peut prendre la forme d’un mot de passe à retaper ou d’un code envoyé par e-mail.

Paramétrage des cookies en mode sécurisé

Les développeurs peuvent configurer les cookies de session en mode SameSite=Strict ou SameSite=Lax. Ce réglage interdit l’envoi automatique des cookies lorsqu’une requête provient d’un site différent, limitant ainsi les attaques inter-domaines.


Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *