☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

- Travaillez-vous dans une entreprise de **cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) ! - Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family) - Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com) - **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) **groupe Discord** ou le [**groupe telegram**](https://t.me/peass) ou **suivez-moi** sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.** - **Partagez vos astuces de piratage en soumettant des PR au [repo hacktricks](https://github.com/carlospolop/hacktricks) et au [repo hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.

## Description Si un attaquant peut **contrôler un sous-domaine ou le domaine d'une entreprise ou trouve un XSS dans un sous-domaine**, il pourra effectuer cette attaque. Comme indiqué dans la section Cookies Hacking, lorsqu'un **cookie est défini pour un domaine (en le spécifiant), il sera utilisé dans le domaine et les sous-domaines.** {% hint style="danger" %} Par conséquent, **un attaquant sera en mesure de définir pour le domaine et les sous-domaines un cookie spécifique en faisant quelque chose comme** `document.cookie="session=1234; Path=/app/login; domain=.example.com"` {% endhint %} Cela peut être dangereux car l'attaquant peut être en mesure de : * **Fixer le cookie de la victime sur le compte de l'attaquant** de sorte que si l'utilisateur ne remarque pas, **il effectuera les actions dans le compte de l'attaquant** et l'attaquant peut obtenir des informations intéressantes (vérifier l'historique des recherches de l'utilisateur sur la plateforme, la victime peut définir sa carte de crédit dans le compte...) * Si le **cookie ne change pas après la connexion**, l'attaquant peut simplement **fixer un cookie**, attendre que la victime se connecte, puis **utiliser ce cookie pour se connecter en tant que victime**. * Si le **cookie définit une valeur initiale** (comme dans Flask où le **cookie** peut **définir** le **jeton CSRF** de la session et cette valeur sera maintenue après la connexion de la victime), l'**attaquant peut définir cette valeur connue et ensuite l'exploiter** (dans ce scénario, l'attaquant peut ensuite faire effectuer une demande CSRF à l'utilisateur car il connaît le jeton CSRF). ## Ordre des cookies Lorsqu'un navigateur reçoit deux cookies avec le même nom **affectant partiellement la même portée** (domaine, sous-domaines et chemin), le **navigateur enverra les deux valeurs du cookie** lorsque les deux sont valides pour la demande. En fonction de celui qui a **le chemin le plus spécifique** ou de celui qui est **le plus ancien**, le navigateur **définira d'abord la valeur du cookie** puis la valeur de l'autre comme dans : `Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;` La plupart des **sites Web n'utiliseront que la première valeur**. Ainsi, si un attaquant veut définir un cookie, il est préférable de le définir avant qu'un autre ne soit défini ou de le définir avec un chemin plus spécifique. {% hint style="warning" %} De plus, la capacité à **définir un cookie dans un chemin plus spécifique** est très intéressante car vous pourrez faire travailler la **victime avec son cookie sauf dans le chemin spécifique où le cookie malveillant défini sera envoyé en premier**. {% endhint %} ## Contournement de la protection Une protection possible contre cette attaque serait que le **serveur Web n'accepte pas les demandes avec deux cookies avec le même nom mais deux valeurs différentes**. Pour contourner le scénario où l'attaquant définit un cookie après que la victime ait déjà reçu le cookie, l'attaquant pourrait provoquer un **débordement de cookie** et ensuite, une fois que le **cookie légitime est supprimé, définir le malveillant**. {% content-ref url="cookie-jar-overflow.md" %} [cookie-jar-overflow.md](cookie-jar-overflow.md) {% endcontent-ref %} Un autre **contournement** utile pourrait être de **coder l'URL avec le nom du cookie** car certaines protections vérifient deux cookies avec le même nom dans une demande, puis le serveur décoder les noms des cookies. ## Bombe de cookies Une attaque de Cookie Tossing peut également être utilisée pour effectuer une attaque de **Bombe de cookies** : {% content-ref url="cookie-bomb.md" %} [cookie-bomb.md](cookie-bomb.md) {% endcontent-ref %} ## Défenses ### **Utilisez le préfixe `__Host` dans le nom du cookie** * Si un nom de cookie a ce préfixe, il **ne sera accepté que** dans une directive Set-Cookie s'il est marqué Secure, a été envoyé depuis une origine sécurisée, ne comprend pas d'attribut Domain et a l'attribut Path défini sur / * **Cela empêche les sous-domaines de forcer un cookie sur le domaine apex car ces cookies peuvent être considérés comme "verrouillés sur le domaine"** ## Références * [**@blueminimal**](https://twitter.com/blueminimal) * [**https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers**](https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers) * [**https://github.blog/2013-04-09-yummy-cookies-across-domains/**](https://github.blog/2013-04-09-yummy-cookies-across-domains/)