Checklist

1. Critère pour avoir une CSRF

• Avoir une action pertinente (relevant action) : Ex => Changer un mot de passe ou un mail

• Cette action est basé sur le cookie de session : Avoir un Cookie de session

• Ne pas avoir de paramètre imprédictible

Si il y a un paramètre imprédictible (CSRF Token), il est nécéssaire de réaliser les test suivant afin de savoir si il est possible de bypass ce token :

2. Bypass CSRF token

• Supprimer le CSRF token et voir si la requête est accepté

• Changer la méthode POST en GET

• Déterminer si le csrf token est lien à notre jeton de session : Exemple => récupérer un token valide de notre compte et l'essayer sur un autre compte.

Si encore une fois, nous somme en présence d'un csrf token et d'un cookie csrf, faites les choses suivante :

3. Bypass CSRF token et CSRF Cookie

• Checker si le csrf token est lié au csrf cookie :

  • En soumettant un csrf token invalide

  • En soumettant un csrf token valide d'un autre compte

• Soumettre un csrf token et un cookie csrf valide mais d'un autre compte (si ça passe on faire ceci :

  • Reussir à injecter dans les headers http notre cookies csrf (HTTP Header injection)

  • Procéder à l'attaque CSRF

Payload intéressante pour de l'injection de header cookie :

<img src="https://YOUR-LAB-ID.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrfKey=YOUR-KEY%3b%20SameSite=None" onerror="document.forms[0].submit()">

4. Bypass CSRF token & CSRF Cookie identique:

Par moment il est possible que le csrf token et le csrf cookie soit identique et que la vérification se fasse sur l'égalité des deux.

• Essayer de mettre deux tokens différents et observer la réponse

• Essayer de mettre deux tokens identique et observer la réponse : si c'est bon alors le csrf token est prédictible puisqu'on le contrôle

5. Les cookies présente l'attribut SameSite Strict/Lax

Ressource :

SameSite cookies explainedweb.dev

Schéma :

5.1 L'attribut Strict :

Pour réussir à forger une csrf avec un cookie présentant l'attribut strict, il faut réussir à trouver une vulnérabilité qu'on nomme open redirection. Effectivement, il est nécessaire de trouver dans le site web une fonction faisant une redirection et sur laquelle on peut forger notre redirection. Le fonctionnement est simple, la victime va cliquer sur le lien mais le cookie ne sera pas envoyé mais la redirection qu'on aurait pu faire réalisé à la victime va elle contenir le cookie. Ainsi si on arrive a rediriger notre victime vers la bonne fonction (ex changemail?mail=[e-mail]) alors la CSRF est possible

5.2 L'attribut Lax

Les restrictions Lax SameSite signifient que les navigateurs enverront le cookie dans les requêtes intersites, mais uniquement si les deux conditions suivantes sont remplies :

• La requête utilise la méthode GET.

• La demande résultait d'une navigation de haut niveau par l'utilisateur, telle qu'un clic sur un lien.

Cela signifie que le cookie n'est pas inclus dans les requêtes POST intersites, par exemple. Comme les requêtes POST sont généralement utilisées pour effectuer des actions qui modifient des données ou un état (au moins selon les meilleures pratiques), elles sont beaucoup plus susceptibles d'être la cible d'attaques CSRF.

Pour ce faire il faut donc :

• Forcer à forger une requête de type GET.

HTTP Method Override – what it is and how a pentester can use it | SideChannel – Tempest

Exemple :

Lorsqu'on overwrite la méthode, on trompe en réalité le navigateur pour qu'il envoie le cookie et côté backend on l'interprète en POST.

6. CSRF basé sur le referer Header

Certains site web utilise le referer header afin de connaitre d'ou la requête a été initié. Si celle-ci a été initié depuis un site différents alors la requête n'est pas valide.

Ainsi on peut bypass,cette protection si celle-ci est mal utilisé :

• Supprimer ce header car parfois la validation de celui-ci depends de sa présence.

<meta name="referrer" content="never">