Cross-Site Request Forgery (CSRF)
Le Cross-Site Request Forgery (CSRF), ou falsification de requête inter-site, est une vulnérabilité web permettant à un attaquant de forcer un utilisateur authentifié à exécuter des actions non souhaitées sur une application Web. Cette attaque exploite la confiance qu'un site accorde à l'utilisateur connecté, et peut entraîner des conséquences graves : modification de paramètres, transfert d'argent, ou actions administratives non autorisées.
Principe de l'attaque
Le CSRF repose sur trois éléments clefs :
- L'utilisateur est déjà authentifié sur le site cible (par exemple via un cookie de session).
- L'attaquant crée une page ou un lien malveillant contenant une requête HTTP vers le site ciblé.
- L'utilisateur, en visitant la page de l'attaquant, exécute involontairement la requête avec ses droits authentifiés.
Exemple : un formulaire de transfert bancaire sur un site est soumis à l'insu de l'utilisateur via une page malveillante ouverte dans son navigateur.
Différence avec d'autres vulnérabilités
| Vulnérabilité | Description |
|---|---|
| XSS (Cross-Site Scripting) | Exploite la confiance de l'utilisateur envers le site. |
| CSRF | Exploite la confiance du site envers l'utilisateur authentifié. |
Ainsi, le CSRF est souvent qualifié de vulnérabilité liée aux sessions et à l'authentification.
Conséquences possibles
Les attaques CSRF peuvent provoquer :
- modification de mots de passe ou d'adresses de courriel,
- transactions financières non autorisées,
- changement de droits ou suppression de contenu,
- exploitation pour accéder à des fonctions administratives.
En bref, tout ce que l'utilisateur authentifié peut faire, l'attaquant peut le faire à sa place.
Techniques de protection
Plusieurs méthodes permettent de se prémunir contre le CSRF :
Token CSRF
- Génération d'un jeton unique pour chaque session ou formulaire.
- Le jeton est vérifié à chaque requête critique.
- Sans le jeton valide, la requête est rejetée.
Vérification de l'en-tête Referer / Origin
Certains serveurs vérifient que la requête provient du même domaine que l'application.
Double soumission de cookie
Le cookie d'authentification est accompagné d'un token dans le corps ou l'en-tête de la requête.
Limitation des actions sensibles aux méthodes POST
Les requêtes GET ne doivent jamais provoquer de changements dans l'application.
Bonnes pratiques
- Utiliser des cadres d'applications intégrant CSRF automatiquement, comme Laravel, Django ou Spring.
- Ne jamais compter uniquement sur le Referer pour la sécurité.
- Ne pas inclure d'actions critiques dans les URLs (GET).
- Former les développeurs pour qu'ils appliquent systématiquement les protections CSRF.
Normes et recommandations
Le CSRF est identifié comme vulnérabilité par :
- OWASP (OWASP Top 10 : A8 2017 / A10 2021 selon la version)
- NIST (CWE-352 : Cross-Site Request Forgery)
- Guides de bonnes pratiques ISO/IEC 27001 et PCI DSS.
Conclusion
Le CSRF est une faille silencieuse mais puissante. Bien comprise et correctement contrée, elle protège l'intégrité des actions des utilisateurs authentifiés et réduit considérablement les risques de compromission des applications web. L'implémentation de jetons CSRF, combinée à des pratiques de développement sécurisées, reste la mesure de protection la plus efficace.