La falsification de requête inter-sites, plus connue sous le sigle CSRF (Cross-Site Request Forgery), est une faille web discrète mais efficace. L’OWASP (Open Worldwide Application Security Project) la classe depuis des années dans son top 10 des vulnérabilités les plus critiques, alors qu’elle reste souvent négligée.
Comment fonctionne une attaque CSRF ?
Le principe repose sur le fonctionnement du navigateur, qui envoie automatiquement les cookies associés à un domaine, quelle que soit l’origine de la requête. Si un utilisateur est connecté à kiwi-banque.fr et qu’un site tiers envoie une requête vers ce domaine en son nom, le navigateur joint le cookie de session sans lui demander son avis. Le serveur considère alors que c’est l’utilisateur qui a agi.
L’attaquant n’a donc pas besoin de connaître le mot de passe, puisque le cookie suffit à reconnaître la victime. L’exemple décrit dans l’article est celui d’un lien vers un site consacré aux capybaras, qui contiendrait une image invisible pointant vers une action de virement. Si le script de virement ne vérifie pas l’origine de la requête, le virement est effectué. Pour rester lisible, l’auteur précise que les pages réelles d’un service bancaire sont plus complexes et n’acceptent pas un montant dans un simple paramètre. Le même mécanisme peut toucher un changement d’adresse e-mail, la publication d’un message, la suppression d’un compte ou la modification d’un mot de passe.
Le token CSRF, la défense la plus répandue
La protection la plus courante consiste à utiliser un token CSRF. Le serveur génère une chaîne de caractères aléatoire, unique par session ou par formulaire, et l’insère dans chaque formulaire HTML sous forme de champ caché. Lors de la soumission, il vérifie que le token reçu correspond à celui qu’il a généré.
Un attaquant situé sur un autre domaine ne peut pas lire le contenu de la page de la victime, donc il ne peut pas connaître ce token. La requête forgée est alors rejetée. L’article rappelle que l’utilisation de requêtes POST pour les actions sensibles est une bonne pratique, mais qu’elle ne protège pas à elle seule, car un formulaire placé sur un site tiers peut soumettre une requête POST vers votre domaine.
Les frameworks et CMS modernes, comme Laravel, Symfony ou WordPress, intègrent souvent déjà ces mécanismes. Selon l’article, il suffit parfois d’une option à activer ou d’une ligne de code. WordPress utilise pour sa part des nonces (number used once), qui remplissent la même fonction sans être un token CSRF au sens strict. Les navigateurs prennent aussi en charge l’attribut SameSite sur les cookies, présenté comme une couche de protection supplémentaire, mais pas comme un remplacement de la vérification côté serveur.
Ce qu’il ne faut pas faire
Vérifier uniquement les en-têtes Referer ou Origin ne suffit pas. Ils peuvent être absents, certains proxys les supprimant, ou, dans des cas rares, manipulés. Ils peuvent servir de contrôle complémentaire, au mieux.
Stocker le token dans le localStorage et l’envoyer dans la query string est également déconseillé. Le localStorage est accessible à tous les scripts du domaine, et un token placé dans l’URL peut se retrouver dans les logs serveur, l’historique du navigateur ou les en-têtes Referer. Enfin, un token non aléatoire, basé sur l’identifiant de l’utilisateur, un horodatage ou un hash prévisible, n’offre aucune protection si quelqu’un parvient à le calculer.
