Qu'est-ce que le CSRF ? Comment pouvons-nous prévenir le CSRF ?

À l'ère numérique, Internet s'est intégré dans le tissu de notre vie quotidienne. Nous avons migré de nombreuses activités en ligne, des achats aux interactions sociales sur diverses plateformes, en passant par les transactions bancaires. Alors que les interactions financières deviennent plus répandues, les conséquences de la sécurité des réseaux se sont accentuées. L'une des menaces cybernétiques les plus répandues sur Internet est la CSRF (Cross-site request forgery), et il est essentiel d'explorer ses nuances.

Qu'est-ce que la CSRF ?

Les attaques CSRF exploitent les vulnérabilités dans les mécanismes de validation des requêtes d'un site web cible. Dans certaines situations, les utilisateurs exécutent involontairement des requêtes malveillantes tout en étant connectés au site web cible. Les attaquants utilisent généralement des adresses ressemblant au domaine du site cible, incitant les utilisateurs à cliquer. Ils intègrent du code malveillant en le déguisant en chargement d'images ou en formulaires cachés, lançant des requêtes vers le site cible et exécutant des actions non autorisées en secret. Des objectifs tels que la modification des mots de passe des utilisateurs ou le lancement de virements bancaires non autorisés peuvent entraîner des pertes importantes pour les utilisateurs.

Exemple concret

Imaginez un site web nommé e-bank.com offrant des services bancaires en ligne, avec une page nommée /transfer pour soumettre des demandes de virement. Lorsque les utilisateurs accèdent à la page e-bank.com/transfer, un formulaire affichant les détails saisis par l'utilisateur est présenté. Une fois le formulaire rempli et soumis, une requête HTTP POST est envoyée à l'adresse de la page, transportant des paramètres comme le destinataire et le montant saisis par l'utilisateur.

À ce stade, un attaquant peut construire une page malveillante avec un formulaire invisible, dirigeant l'adresse de soumission vers e-bank.com/transfer. L'attaquant pré-remplit le formulaire avec les paramètres spécifiques du destinataire et du montant. Lorsque les utilisateurs sont trompés pour cliquer sur cette page malveillante, le navigateur exécute du code JavaScript, soumettant le formulaire.

Si l'utilisateur n'est pas enregistré ou connecté sur e-bank.com, la demande de virement ne peut pas être exécutée. Cependant, si l'utilisateur a récemment utilisé le service et que le statut de connexion persiste, la demande de virement peut être exécutée avec succès.

Cela résume les attaques CSRF—simples en principe mais ayant un potentiel de dommage immense. Heureusement, il existe de nombreuses méthodes matures pour contrer ces attaques. Explorons-les ci-dessous.

Comment pouvons-nous prévenir la CSRF ?

Pour résoudre ce problème, des mesures proactives et passives sont nécessaires.

Restriction des méthodes HTTP et du Referer

En tant que développeurs, nous pouvons imposer des restrictions plus strictes sur les adresses sensibles au sein du service, telles que :

• Pour les adresses nécessitant la soumission de données, interdire l'utilisation des requêtes HTTP GET, forçant l'utilisation des requêtes POST. Cela ajoute de la complexité pour les attaquants tentant de construire des pages malveillantes.

• De plus, nous pouvons restreindre le champ Referer dans l'en-tête de la requête HTTP (Referer), en ne permettant que les adresses légitimes connues et en bloquant les requêtes malveillantes.

Cela représente une mesure de protection proactive simple, avec un coût moindre mais toujours une certaine vulnérabilité aux attaques.

Token CSRF

Le Token CSRF est une solution largement adoptée, combinant les mécanismes de session côté serveur pour contrer les attaques CSRF. Concrètement, le programme côté serveur intègre un champ d'entrée caché sur les pages nécessitant une protection avec un Token CSRF généré aléatoirement dans le formulaire de sortie. Simultanément, une session est créée côté serveur, stockant cette chaîne aléatoire avec un temps d'expiration.

Lorsqu'un utilisateur demande la page, le serveur initialise la session, stockant les données côté serveur et définissant un cookie dans le navigateur côté client contenant l'ID de session pour l'association. Le Token CSRF est stocké dans la session. Lors de la soumission du formulaire, le Token CSRF est envoyé. Le programme côté serveur compare ce token avec la partie stockée dans la session. Une validation réussie conduit à l'exécution de la logique suivante ; sinon, une erreur est renvoyée. Simultanément, un nouveau Token CSRF est inséré dans le formulaire pour la prochaine soumission.

Cela représente une mesure de protection proactive, demandant un certain effort mais offrant une protection robuste.

Protection Cross-Origin

Nous rencontrons souvent une technologie nommée CORS (Cross-Origin Resource Sharing), une spécification indiquant si les navigateurs permettent les requêtes cross-origin. Les navigateurs modernes supportent cette spécification. Lors de l'initiation d'une requête Fetch/XHR sur une page existante, le navigateur envoie une requête HTTP OPTIONS pour pré-vérifier si le service cible permet les requêtes depuis l'adresse source actuelle. Le serveur fournira une liste de headers de réponse, spécifiant les sources autorisées, les méthodes de requête et les headers. Le navigateur respecte ces indications, empêchant les requêtes interdites côté client.

Cela sert de mesure de protection proactive supplémentaire, configurable côté serveur, mais notez que bien que les utilisateurs normaux soient peu susceptibles de désactiver cette fonctionnalité, cela reste possible côté client.

Blocage des cookies tiers

Les services que nous développons stockent parfois les ID de session des utilisateurs dans des cookies pour maintenir le statut de connexion. Les cookies supportent les paramètres SameSite, empêchant le navigateur d'envoyer des cookies aux sites cross-origin. Tenter des attaques CSRF résulte en un statut non authentifié sur le site cible.

De plus, en raison de l'utilisation abusive des mécanismes de cookies HTTP pour le suivi des clients, les développeurs de navigateurs ont décidé de restreindre et de bloquer progressivement les cookies tiers (Cookie Countdown). Lorsqu'une page sur le domaine A tente d'appeler le domaine B, même si elle passe les vérifications des règles CORS, le navigateur n'enverra pas de cookies à ce site cross-origin.

Résumé

En tant que passerelles API, Apache APISIX et API7 Enterprise supportent le Token CSRF et CORS—deux mesures de protection mentionnées précédemment—pour contrer les attaques CSRF.

En conclusion, prévenir les attaques CSRF nécessite une approche multifacette, incorporant diverses techniques à travers le serveur, le navigateur, le protocole HTTP, et plus encore pour atteindre une protection complète.