CSRF Bank Transfer

Le Cross-Site Request Forgery (CSRF) est une vulnérabilité de sécurité web qui trompe les utilisateurs authentifiés pour qu'ils effectuent des actions non intentionnelles sur une application web. Un tutoriel CSRF démontre comment les attaquants créent des pages web malveillantes qui soumettent des requêtes à des sites vulnérables en utilisant la session existante de la victime. Cette attaque est particulièrement dangereuse dans les applications financières où des transferts non autorisés, des changements de mot de passe ou des modifications de compte peuvent se produire à l'insu de l'utilisateur.

Comment fonctionnent les attaques CSRF

Le CSRF exploite la confiance qu'une application web accorde au navigateur de l'utilisateur. Lorsqu'un utilisateur est connecté à un site bancaire, son navigateur inclut automatiquement les cookies de session avec chaque requête vers ce site. Un attaquant peut créer une page web malveillante contenant un formulaire caché qui soumet une demande de transfert au site bancaire. Si la victime visite cette page malveillante tout en étant connectée à sa banque, le navigateur envoie la requête forgée avec des cookies de session valides, et la banque la traite comme une transaction légitime.

Vecteurs d'attaque CSRF

Les attaquants livrent des charges utiles CSRF par diverses méthodes. Les formulaires HTML cachés avec soumission automatique en JavaScript sont la technique la plus courante pour les attaques basées sur POST. Les balises image et autres éléments qui déclenchent des requêtes GET peuvent exploiter les applications qui effectuent des changements d'état via GET. Des attaques plus sophistiquées utilisent des appels XMLHttpRequest ou fetch API, bien que les restrictions de la politique de même origine limitent certaines de ces approches. L'ingénierie sociale joue un rôle clé - l'attaquant doit convaincre la victime de visiter la page malveillante tout en étant authentifiée sur l'application cible.

Défenses contre le CSRF

La défense CSRF la plus efficace est le modèle de jeton synchroniseur, où le serveur génère un jeton unique et imprévisible pour chaque session ou requête et exige qu'il soit inclus dans toutes les requêtes de changement d'état. Puisque l'attaquant ne peut pas lire le jeton depuis le site cible (bloqué par la politique de même origine), il ne peut pas l'inclure dans sa requête forgée. Des défenses supplémentaires incluent les attributs de cookie SameSite, la vérification des en-têtes Origin et Referer, et l'exigence de ré-authentification pour les opérations sensibles comme les transferts financiers.