CSRF

Pour qu'une faille de type CSRF, on doit rencontrer ces trois conditions :

Une action pertinente. Il y a une action dans l'application que l'attaquant a une raison d'induire. Il peut s'agir d'une action privilégiée (telle que la modification des autorisations d'autres utilisateurs) ou de toute action sur des données spécifiques à l'utilisateur (telle que la modification du mot de passe de l'utilisateur).
Gestion de session basée sur les cookies. L'exécution de l'action implique l'émission d'une ou plusieurs requêtes HTTP, et l'application s'appuie uniquement sur les cookies de session pour identifier l'utilisateur qui a fait les requêtes. Il n'existe aucun autre mécanisme en place pour suivre les sessions ou valider les demandes des utilisateurs.
Aucun paramètre de requête imprévisible. Les requêtes qui exécutent l'action ne contiennent aucun paramètre dont les valeurs ne peuvent pas être déterminées ou devinées par l'attaquant. Par exemple, en incitant un utilisateur à changer son mot de passe, la fonction n'est pas vulnérable si un attaquant a besoin de connaître la valeur du mot de passe existant.

1. CSRF Basique :

Le cookie n'a pas le bon attribut ce qui rend possible la csrf

2. Bypass CSRF token

On peut bypass à cause d'une mauvaise implementation de celui-ci ou une mauvaise utilisations

2.1 CSRF verification depends on HTTP methode

On peut contourner le csrf token en changeant la methode http utilisé :

On change la méthode POST en GET et on arrive a bypass :

Résultat avec CSRF PoC generator :

2.3 Bypass en supprimant le token

Dans certaines situations, l'application va vérfié si le token est le bon mais si aucun token ne lui est présenté la vérification n'est pas faite et est juste skip :

J'essaye en mettant un token invalide :

2.4 Bypass : Le jeton CSRF n'est pas lié à la session utilisateur

Certaines applications ne valident pas que le jeton appartient à la même session que l'utilisateur qui fait la demande. Au lieu de cela, l'application gère un pool global de jetons qu'elle a émis et accepte tout jeton qui apparaît dans ce pool.

Dans cette situation, l'attaquant peut se connecter à l'application en utilisant son propre compte, obtenir un jeton valide, puis transmettre ce jeton à l'utilisateur victime dans son attaque CSRF.

Par moment, un cookie csrf peut être présent : Voir si il est lié au csrf token. Utilisé un couple de csrf token/cookie d'un autre compte. Et généralement cela suit avec une injection de header afin d'y insérer le token cookie lié au csrf token