Berceaux de sécurité: CSRF

Malgré le fait que dans la dernière liste publiée des vulnérabilités des attaques CSRF OWASP Top 10 2017 sont classées comme «Supprimées, mais pas oubliées», nous avons décidé qu'il ne serait pas superflu de rappeler à nouveau comment se défendre contre les attaques CSRF, en s'appuyant sur celles les mêmes règles que celles fournies par l'OWASP.

Utilisation du jeton CSRF

L'utilisation d'un jeton (méthodes sans état et avec état) est la méthode de protection principale et la plus populaire. Le jeton doit être unique pour chaque session utilisateur, généré par un générateur de nombres pseudo-aléatoires cryptographiquement robuste. OWASP recommande également d'utiliser les algorithmes AES256-GCM et SHA256 / 512 pour le chiffrement lors de l'utilisation de HMAC.

Il existe plusieurs approches pour travailler avec des jetons: jeton de synchronisation, modèle de jeton basé sur le chiffrement, jeton basé sur HMAC

Jeton de synchroniseur

En utilisant l'approche Synchronizer Token (méthode statefull), cela signifie envoyer un jeton à chaque demande, ce qui implique des modifications côté serveur. Si le jeton n'est pas valide, le serveur rejette la demande.
Lors de l'envoi d'une demande au serveur, il est recommandé d'ajouter un jeton aux paramètres de la demande plutôt qu'à l'en-tête. Si vous insérez néanmoins un jeton dans l'en-tête de la demande, assurez-vous qu'il n'est pas enregistré sur le serveur. Le jeton reçu peut être stocké côté client dans un champ caché:

<form action="/post.php" method="post"> <input type="hidden" name="CSRFToken" value="l5824xNMAYFesBxing975yR8HPJlHZ"> ... </form> 

dans les en-têtes:

 POST /page HTTP/1.1 Accept: application/json, application/xml, text/json, text/x-json, text/javascript, text/xml User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36 Content-Type: application/json Host: example.com X-CSRF-TOKEN: l5824xNMAYFesBxing975yR8HPJlHZ 

ou dans les cookies

 POST /page HTTP/1.1 Host: example.com Set-Cookie: CSRFToken=l5824xNMAYFesBxing975yR8HPJlHZ; Content-Type: application/x-www-form-urlencoded 

OWASP recommande de stocker le jeton dans les en-têtes, expliquant que même si le jeton est ouvert ou expiré, l'attaquant ne pourra toujours pas simuler la demande, en raison des navigateurs.

De plus, pour augmenter le niveau de sécurité de la méthode proposée, il est proposé de générer un nom de paramètre de jeton aléatoire et / ou le jeton lui-même pour chaque requête. Avec cette approche, le temps pendant lequel l'attaquant peut utiliser le jeton volé est minimal. Cependant, cela peut entraîner des problèmes de convivialité. Par exemple, un clic sur le bouton «Retour» peut entraîner l'envoi d'un token invalide au serveur, qui était contenu sur la page précédente.

L'envoi d'un jeton à l'aide d'une demande GET n'est pas recommandé, car avec cette approche, le jeton peut être révélé: dans l'historique du navigateur, les fichiers journaux, les en-têtes de référent.

Jeton basé sur le chiffrement

Cette approche est sans état, car elle utilise le chiffrement / déchiffrement pour valider le jeton et ne nécessite donc pas le stockage du jeton côté serveur.

Le serveur génère un jeton composé d'un identifiant de session et d'un horodatage (pour empêcher une attaque de relecture). Pour le chiffrement, il est recommandé d'utiliser l'algorithme de chiffrement AES256 en mode de chiffrement par bloc GSM / GSM-SIV. L'utilisation du mode ECB est fortement déconseillée. Le jeton chiffré par le serveur est retourné au client de la même manière que dans le cas de «Synchronizer Token» dans le champ de formulaire masqué ou dans l'en-tête / paramètre de réponse. À la réception du jeton, le serveur doit le déchiffrer, puis vérifier l'identifiant de session et également vérifier l'horodatage avec l'heure actuelle et s'assurer qu'il ne dépasse pas la durée de vie du jeton définie.
Si la vérification de l'identifiant de session réussit, mais pas la chronologie, la demande peut être considérée comme valide. Dans tous les autres cas, il est recommandé de rejeter la demande et de l'enregistrer afin de mieux comprendre comment répondre à ces demandes.

Jeton basé sur HMAC

Il ne nécessite pas non plus de stockage de jeton, le principe de fonctionnement est similaire au jeton basé sur le chiffrement, sauf qu'au lieu de chiffrer le jeton, la fonction HMAC (code d'authentification de message basé sur le hachage) est utilisée pour générer le jeton (il est recommandé d'utiliser SHA256 ou un algorithme plus puissant). Dans ce cas, le jeton est le résultat de la fonction HMAC de l'identifiant de session utilisateur + horodatage.

Automatisation des jetons

Le principal problème dans la lutte contre les attaques CSRF est que les développeurs oublient souvent simplement d'ajouter des fonctionnalités pour travailler avec des jetons. Pour éviter de tels problèmes, il vaut la peine d'automatiser ce processus:

• écrire un wrapper qui ajoute automatiquement un jeton aux requêtes via la balise form ou lors de l'utilisation d'ajax. Par exemple, Spring Security adopte une approche similaire chaque fois que la balise <form: form> est utilisée.

• écrire un hook qui intercepte le trafic et ajoute des jetons à toutes les ressources vulnérables. Puisqu'il est assez difficile d'analyser quelle demande le changement d'état effectue, nécessitant un jeton, il est recommandé d'inclure des jetons dans toutes les réponses POST, mais cela vaut la peine de considérer le coût des performances

• ajouter automatiquement un jeton lors du rendu d'une page. Cette approche est utilisée par CSRF Guard: des jetons sont ajoutés à tous les attributs href et src, aux champs cachés et dans toutes les formes

Avant d'essayer d'écrire votre propre système de génération automatique de jetons, il est recommandé de préciser si le framework que vous utilisez a la capacité de fournir une protection contre les attaques CSRF par défaut. Par exemple, le même framework Django implémente une protection contre CSRF.


Connexion CSRF

En utilisant CSRF dans le formulaire de connexion, un attaquant peut se connecter,
déguisé en victime. De telles vulnérabilités ont été rencontrées par des géants tels que PayPal et Google.
Vous pouvez gérer CSRF dans le formulaire de connexion en créant des pré-sessions qui sont créées avant l'authentification de l'utilisateur et en incluant des jetons dans le formulaire de connexion.


Cookie Samesite

SameSite Cookie est un attribut décrit dans la RFC6265bis dont le but est de contrer les attaques CSRF. Cela fonctionne comme suit. L'une des méthodes de protection consiste à vérifier l'origine et les en-têtes de référent, grâce auxquels vous pouvez comprendre d'où provient la demande, mais cette approche nécessite la mise en œuvre d'un mécanisme de vérification. En utilisant l'attribut SameSite, nous restreignons l'envoi de cookies avec une demande de ressources étrangères. Cet attribut a plusieurs valeurs possibles: Strict, Lax et None.
L'utilisation de la valeur stricte signifie que le navigateur n'enverra pas de cookies provenant de sources qui ne correspondent pas au nom de domaine de la ressource actuelle.
La valeur lax permet de ne pas bloquer les cookies des ressources externes, dont la transition a été effectuée de manière sécurisée - en utilisant le protocole HTTPS. Lax établit un équilibre entre convivialité et sécurité.

La définition d'un attribut est assez simple:

 Set-Cookie: JSESSIONID=xxxxx; SameSite=Strict Set-Cookie: JSESSIONID=xxxxx; SameSite=Lax 

Au moment de la rédaction, la prise en charge de l'attribut par les navigateurs ressemble à ceci:




Il est important de se rappeler que cet attribut doit être utilisé comme mesure de protection supplémentaire et non comme un moyen de se passer de l'utilisation du jeton CSRF.

Vérification des en-têtes

Comme mentionné ci-dessus, l'une des méthodes de protection consiste à vérifier les valeurs de référence et d'origine de l'en-tête de demande.
L'essence de cette vérification est de vérifier les valeurs des en-têtes côté serveur. S'ils correspondent à la ressource, la demande est considérée comme correcte, sinon elle est rejetée. Si l'en-tête Origin est manquant, vous devez vous assurer que la valeur Referrer correspond à la ressource actuelle. OWASP recommande de rejeter les demandes qui ne contiennent pas d'en-têtes Origin ou Referrer. Vous pouvez également enregistrer toutes ces demandes afin de les analyser plus tard et de décider comment les traiter.

Cependant, les choses se compliquent si votre application se trouve derrière un serveur proxy, car l'URL dans l'en-tête sera différente. Dans ce cas, il existe plusieurs options:
• Configurez votre application afin de toujours connaître l'origine de la demande. Le problème avec cette approche est de définir la bonne valeur si votre application est déployée dans plusieurs environnements (par exemple, dev, QA, production), ce qui conduit à un problème de support
• utilisez l'en-tête Host. Cet en-tête vous permettra de déterminer la source de la demande, quel que soit l'environnement.
• utiliser l'en-tête X-Forwarded-Host, dont le but est de stocker les en-têtes d'origine reçus par le serveur proxy

Toutes les méthodes décrites ne fonctionnent que lorsque les en-têtes d'origine et de référence sont présents. Mais il y a des cas où ces en-têtes sont manquants. Voici quelques cas où ces en-têtes ne sont pas inclus dans la demande:
• IE 11 n'inclut pas l'en-tête Origin pour les sites de confiance. Il ne reste plus qu'à s'appuyer sur l'en-tête Referer.
• dans le cas d'une redirection, Origin n'est pas inclus dans la demande, car on pense qu'il peut contenir des informations confidentielles qui ne devraient pas être envoyées à une autre source
• L'en-tête d'origine est activé pour toutes les demandes intersites, mais la plupart des navigateurs l'ajoutent uniquement pour les demandes POST / DELETE / PUT

En règle générale, une petite quantité de trafic tombe dans les catégories décrites, mais souvent vous ne voulez pas perdre même cette petite partie d'utilisateurs, par conséquent, il est considéré comme valide de demander avec une valeur nulle pour origin / referrer ou avec une valeur correspondant à la liste des domaines de confiance.

Double soumettre le cookie

Cette approche est assez simple à implémenter et ne nécessite pas de stockage du token côté serveur (sans état). L'essence de la méthode est d'envoyer le jeton dans le paramètre de demande et dans les cookies par l'utilisateur. Pour chaque demande nécessitant un changement d'état, nous vérifions la valeur du jeton dans les cookies et dans la demande. Si la vérification de l'identifiant de session réussit, mais pas la chronologie, la demande peut être considérée comme valide