# Cookie Tossing

{{#include ../../banners/hacktricks-training.md}}

### 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 sera capable d'effectuer cette attaque.

Comme indiqué dans la section Hacking des Cookies, lorsqu'un **cookie est défini pour un domaine (en le spécifiant), il sera utilisé dans le domaine et les sous-domaines.**

> [!CAUTION]
> Par conséquent, **un attaquant pourra 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"`

Cela peut être dangereux car l'attaquant peut être en mesure de :

- **Fixer le cookie de la victime au compte de l'attaquant** afin que si l'utilisateur ne s'en rend pas compte, **il effectuera les actions dans le compte de l'attaquant** et l'attaquant pourra obtenir des informations intéressantes (vérifier l'historique des recherches de l'utilisateur sur la plateforme, la victime peut enregistrer sa carte de crédit dans le compte...)
- Un exemple de cela [peut être trouvé ici](https://snyk.io/articles/hijacking-oauth-flows-via-cookie-tossing/) où l'attaquant a défini son cookie dans des sections spécifiques qu'une victime utilisera pour autoriser **l'accès à ses dépôts git mais depuis le compte de l'attaquant** car il définira ses cookies dans les points de terminaison nécessaires.
- Si le **cookie ne change pas après la connexion**, l'attaquant peut simplement **fixer un cookie (session-fixation)**, attendre que la victime se connecte et ensuite **utiliser ce cookie pour se connecter en tant que victime**.
- Parfois, même si les cookies de session changent, l'attaquant utilise l'ancien et il recevra également le nouveau.
- Si le **cookie définit une valeur initiale** (comme dans flask où le **cookie** peut **définir** le **token CSRF** de la session et cette valeur sera maintenue après que la victime se soit connectée), l'**attaquant peut définir cette valeur connue et ensuite en abuser** (dans ce scénario, l'attaquant peut alors amener l'utilisateur à effectuer une requête CSRF car il connaît le token CSRF).
- Tout comme définir la valeur, l'attaquant pourrait également obtenir un cookie non authentifié généré par le serveur, obtenir le token CSRF à partir de celui-ci et l'utiliser.

### Cookie Order

Lorsqu'un navigateur reçoit deux cookies avec le même nom **affectant partiellement le même champ** (domaine, sous-domaines et chemin), le **navigateur enverra les deux valeurs du cookie** lorsque les deux sont valides pour la requête.

Selon qui a **le chemin le plus spécifique** ou lequel 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**. Donc, 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.

> [!WARNING]
> De plus, la capacité à **définir un cookie dans un chemin plus spécifique** est très intéressante car vous pourrez faire en sorte que la **victime travaille avec son cookie sauf dans le chemin spécifique où le cookie malveillant sera envoyé en premier**.

### Protection Bypass

Une protection possible contre cette attaque serait que le **serveur web n'accepte pas les requêtes avec deux cookies ayant 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 le **cookie légitime supprimé, définir le malveillant**.

{{#ref}}
cookie-jar-overflow.md
{{#endref}}

Un autre **bypass** utile pourrait être de **coder en URL le nom du cookie** car certaines protections vérifient 2 cookies avec le même nom dans une requête et ensuite le serveur décodera les noms des cookies.

### Cookie Bomb

Une attaque de Cookie Tossing peut également être utilisée pour effectuer une attaque **Cookie Bomb** :

{{#ref}}
cookie-bomb.md
{{#endref}}

### Defense**s**

#### **Utiliser le préfixe `__Host` dans le nom du cookie**

- Si un nom de cookie a ce préfixe, il **ne sera accepté** dans une directive Set-Cookie que s'il est marqué Secure, a été envoyé depuis une origine sécurisée, n'inclut pas d'attribut Domain, et a l'attribut Path défini sur /
- **Cela empêche les sous-domaines de forcer un cookie au domaine principal puisque ces cookies peuvent être considérés comme "verrouillés au domaine"**

### References

- [**@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/)
- [**Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities**](https://www.youtube.com/watch?v=F_wAzF4a7Xg)

{{#include ../../banners/hacktricks-training.md}}