Cross-Site Request Forgery (CSRF)

Falsification de requête intersite (CSRF) piège le navigateur d'un utilisateur authentifié pour qu'il envoie des requêtes non autorisées à une application web. Le navigateur envoie automatiquement les cookies avec les requêtes ; sans mesures supplémentaires, le serveur ne peut donc pas distinguer les requêtes légitimes des requêtes falsifiées.

Scénario :

1. La victime est connectée à bank.com (cookie de session dans le navigateur)
2. La victime visite la page de l'attaquant contenant : <img src="https://bank.com/transfer?to=attacker&amount=1000">
3. Le navigateur envoie la requête GET avec le cookie de bank.com joint
4. La banque traite le virement

Une attaque CSRF avec POST nécessite un formulaire :

La principale défense est un jeton CSRF : une valeur aléatoire et secrète, propre à chaque session (ou à chaque requête), intégrée aux formulaires. Le serveur valide le jeton pour chaque requête qui modifie l'état. Un attaquant situé sur un autre domaine ne peut pas lire le jeton (politique de même origine).

SameSite=Strict : le cookie n'est jamais envoyé avec des requêtes intersites. SameSite=Lax : le cookie est envoyé lors des navigations sûres de premier niveau (liens), mais pas avec une requête POST provenant d'autres sites. Les navigateurs modernes utilisent Lax par défaut, ce qui réduit considérablement le risque de CSRF.

Une solution de remplacement au stockage des jetons côté serveur : définissez un cookie CSRF aléatoire et exigez qu'il soit également envoyé comme paramètre de requête. Un attaquant ne peut pas lire le cookie (même origine) et ne peut donc pas le faire correspondre aux données du formulaire.

Pour les requêtes AJAX, exiger un en-tête personnalisé (par exemple, X-Requested-With: XMLHttpRequest) fournit une protection contre CSRF, car les navigateurs empêchent les scripts interorigines de définir des en-têtes arbitraires (CORS applique cette règle).

Les jetons CSRF échouent dans les cas suivants :

• Un XSS existe : l'attaquant peut lire le jeton avec JavaScript
• Le jeton est divulgué dans l'URL (en-tête Referer)
• Le jeton est prévisible ou réutilisé
• CORS est mal configuré et autorise l'origine de l'attaquant

Étapes de test :

1. Identifiez les requêtes qui modifient l'état (POST, PUT, DELETE)
2. Supprimez ou modifiez le jeton CSRF, puis renvoyez la requête
3. Créez une soumission de formulaire interorigine et vérifiez si elle aboutit
4. Vérifiez l'attribut SameSite des cookies de session

Les API REST qui utilisent JSON sont souvent exemptées de protection contre CSRF si elles :

• Exigent Content-Type: application/json (les formulaires HTML ne peuvent pas définir cet en-tête)
• Utilisent une authentification par jeton (en-tête Authorization, et non des cookies)

En revanche, les API qui acceptent des cookies doivent tout de même mettre en œuvre une protection contre CSRF.

SameSite=Lax étant la valeur par défaut dans Chrome, Firefox et Safari, de nombreuses attaques CSRF traditionnelles sont bloquées. Toutefois, les attaques visant les sous-domaines et certains modes de navigation peuvent encore contourner Lax. Combinez SameSite avec des jetons CSRF pour une défense robuste.

Quelle est la principale défense contre les attaques CSRF dans les applications web ?

CSRF exploite l'ajout automatique des cookies par le navigateur pour forger des requêtes authentifiées depuis des sites malveillants. Défense principale : jetons CSRF validés côté serveur. Défense secondaire : attribut de cookie SameSite=Strict/Lax. Les API utilisant une authentification par jeton dans les en-têtes (et non des cookies) résistent naturellement au CSRF. Combinez les défenses ; un XSS peut contourner les jetons CSRF s'il est présent.