<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Obtenez le [**merchandising officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**La Famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection d'[**NFTs exclusifs**](https://opensea.io/collection/the-peass-family)
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Partagez vos astuces de piratage en soumettant des PR aux dépôts github** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
Rejoignez le serveur [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) pour communiquer avec des hackers expérimentés et des chasseurs de primes de bugs !
**La falsification de requête intersite** (également connue sous le nom de CSRF) est une vulnérabilité de sécurité Web qui permet à un attaquant d'**induire les utilisateurs à effectuer des actions qu'ils n'ont pas l'intention de réaliser**.\
Cela se fait en **faisant accéder un utilisateur connecté** sur la plateforme victime à un site Web contrôlé par l'attaquant et de là **exécuter** du code JS malveillant, envoyer des formulaires ou récupérer des "images" vers le **compte des victimes**.
Pour pouvoir abuser d'une vulnérabilité CSRF, vous devez d'abord **trouver une action pertinente à abuser** (changer de mot de passe ou d'email, faire en sorte que la victime vous suive sur un réseau social, vous donner plus de privilèges...). La **session doit reposer uniquement sur des cookies ou l'en-tête d'authentification HTTP de base**, aucun autre en-tête ne peut être utilisé pour gérer la session. Enfin, il **ne devrait pas y avoir de paramètres imprévisibles** dans la requête.
* [**Cookies SameSite**](hacking-with-cookies/#samesite) : Si le cookie de session utilise ce drapeau, vous ne pourrez peut-être pas envoyer le cookie à partir de sites Web arbitraires.
* [**Partage de ressources entre origines**](cors-bypass.md) : Selon le type de requête HTTP que vous devez effectuer pour abuser de l'action pertinente, vous pouvez prendre en compte la **politique CORS du site victime**. _Notez que la politique CORS n'aura pas d'effet si vous voulez juste envoyer une requête GET ou une requête POST à partir d'un formulaire et que vous n'avez pas besoin de lire la réponse._
* Demander le **mot de passe** de l'utilisateur pour autoriser l'action.
* Résoudre un **captcha**
* Lire les en-têtes **Referrer** ou **Origin**. Si une regex est utilisée, elle pourrait être contournée par exemple avec :
* http://mal.net?orig=http://example.com (se termine par l'url)
* http://example.com.mal.net (commence par l'url)
* **Modifier** le **nom** des **paramètres** de la requête Post ou Get
* Utiliser un **jeton CSRF** dans chaque session. Ce jeton doit être envoyé à l'intérieur de la requête pour confirmer l'action. Ce jeton pourrait être protégé avec CORS.
Peut-être que le formulaire que vous souhaitez abuser est préparé pour envoyer une **requête POST avec un jeton CSRF mais**, vous devriez **vérifier** si un **GET** est également **valide** et si lorsque vous envoyez une requête GET le **jeton CSRF est toujours validé**.
Certaines applications **valident correctement le jeton lorsqu'il est présent mais sautent la validation si le jeton est omis**.\
Dans cette situation, l'attaquant peut **supprimer entièrement le paramètre** contenant le jeton (pas seulement sa valeur) pour contourner la validation et mener une attaque CSRF.
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 **maintient 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**, et ensuite **transmettre ce jeton à l'utilisateur victime** dans son attaque CSRF.
Si la requête utilise une **méthode "étrange"**, vérifiez si la fonctionnalité de **surcharge de méthode** fonctionne.\
Par exemple, si elle **utilise une méthode PUT**, vous pouvez essayer d'**utiliser une méthode POST** et **envoyer** : _https://example.com/my/dear/api/val/num?**\_method=PUT**_
Dans une variation supplémentaire sur la vulnérabilité précédente, certaines applications **dupliquent chaque jeton dans un cookie et un paramètre de requête**. Ou elles **définissent un cookie csrf** et **vérifient dans le backend si le jeton csrf envoyé est celui lié au cookie**.
Lorsque la requête suivante est validée, l'application vérifie simplement que le **jeton** soumis dans le **paramètre de requête correspond** à la valeur stockée par le **cookie**.\
Dans cette situation, l'attaquant peut à nouveau effectuer une attaque CSRF **si le site Web contient une vulnérabilité qui lui permettrait de définir son cookie CSRF pour la victime comme un CRLF**.
Notez que si le **jeton csrf est lié au cookie de session, cette attaque ne fonctionnera pas** car vous devrez définir la session de la victime pour vous-même, et donc vous vous attaquerez vous-même.
Selon [**ceci**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests), pour **éviter les requêtes preflight** en utilisant la méthode **POST**, voici les valeurs de Content-Type autorisées :
Cependant, notez que la **logique des serveurs peut varier** en fonction du **Content-Type** utilisé, donc vous devriez essayer les valeurs mentionnées et d'autres comme **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._
Comme vous le savez déjà, vous ne pouvez pas envoyer une requête POST avec le Content-Type **`application/json`** via un formulaire HTML, et si vous essayez de le faire via **`XMLHttpRequest`**, une requête de **pré-vol** est d'abord envoyée.\
Cependant, vous pourriez essayer d'envoyer les données JSON en utilisant les types de contenu \*\*`text/plain` et `application/x-www-form-urlencoded` \*\* juste pour vérifier si le backend utilise les données indépendamment du Content-Type.\
Si le serveur n'accepte que le type de contenu "application/json", vous pouvez **envoyer le type de contenu "text/plain; application/json"** sans déclencher de requête de pré-vol.
Vous pourriez également essayer de **contourner** cette restriction en utilisant un **fichier flash SWF**. Pour plus d'informations [**lisez ce post**](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937).
La première partie de [**ce compte-rendu de CTF**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) explique que dans [le code source d'Oak](https://github.com/oakserver/oak/blob/main/router.ts#L281), un routeur est configuré pour **traiter les requêtes HEAD comme des requêtes GET** sans corps de réponse - une solution courante qui n'est pas propre à Oak. Au lieu d'un gestionnaire spécifique pour les requêtes HEAD, elles sont simplement **transmises au gestionnaire GET mais l'application supprime le corps de la réponse**.
Si un **jeton CSRF** est utilisé comme **défense**, vous pourriez essayer de **l'exfiltrer** en abusant d'une vulnérabilité [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) ou d'une vulnérabilité de [**Dangling Markup**](dangling-markup-html-scriptless-injection/).
xh.setRequestHeader('Content-type', 'application/x-www-form-urlencoded'); //to send proper header info (optional, but good to have as it may sometimes not work without this)
Le code peut être utilisé pour forcer brutalement un formulaire de connexion utilisant un jeton CSRF (Il utilise également l'en-tête X-Forwarded-For pour tenter de contourner un éventuel blocage d'IP) :
Rejoignez le serveur [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) pour communiquer avec des hackers expérimentés et des chasseurs de primes de bugs !
<summary><strong>Apprenez le hacking AWS de zéro à héros avec</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Obtenez le [**merchandising officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**La Famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection d'[**NFTs**](https://opensea.io/collection/the-peass-family) exclusifs
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez**-moi sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Partagez vos astuces de hacking en soumettant des PR aux dépôts github** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).