# Piratage de cookies
☁️ 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**](https://discord.gg/hRep4RUj7f) 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).
## Attributs des cookies ### Expires & Max-Age * `Expires` définit une date d'expiration pour la suppression d'un cookie * `Max-age` définit le temps en secondes pour la suppression d'un cookie **(utilisez cela, ce n'est plus 2009)** ### **Domaine** L'attribut `Domain` spécifie **quels hôtes peuvent recevoir un cookie**. S'il n'est pas spécifié, l'attribut **par défaut** est le **même hôte** qui a défini le cookie, _**à l'exclusion des sous-domaines**_. **Si `Domain` est spécifié**, alors **les sous-domaines sont toujours inclus**. Par conséquent, spécifier `Domain` est moins restrictif que l'omission. Cependant, cela peut être utile lorsque les sous-domaines doivent partager des informations sur un utilisateur. Par exemple, si vous définissez `Domain=mozilla.org`, les cookies sont disponibles sur des sous-domaines tels que `developer.mozilla.org`. Mais si vous ne le faites pas, le cookie ne sera pas envoyé aux sous-domaines. Si un **sous-domaine** `sub.example.com` **définit un cookie** avec l'attribut _domain_ de **`.example.com`**, il sera **envoyé** sur les demandes du **domaine parent**. ### **Chemin** L'attribut `Path` indique un **chemin d'URL qui doit exister dans l'URL demandée pour envoyer l'en-tête `Cookie`**. Le caractère `%x2F` ("/") est considéré comme un séparateur de répertoire, et les sous-répertoires correspondent également. #### Ordre Lorsque 2 cookies ont le **même nom**, celui qui est envoyé est : * Celui avec le **chemin le plus long** correspondant au chemin de l'URL * Le **plus récent** si les deux ont le même chemin ### SameSite Cela indiquera au navigateur si le **cookie** peut être envoyé **à partir d'autres domaines**. Il a 3 valeurs possibles : * **Strict** : Le cookie ne sera pas envoyé avec une demande par des sites Web tiers. * **Lax** : Le cookie sera envoyé avec la demande GET initiée par des sites Web tiers. * **None** : Le cookie est envoyé à partir de n'importe quel domaine tiers. | **Type de demande** | **Code d'exemple** | **Cookies envoyés lorsque** | | ------------------- | ---------------------------------- | --------------------------- | | Lien | \\ | Non défini\*, Lax, None | | Préchargement | \ | Non défini\*, Lax, None | | Formulaire GET | \
| Non défini\*, Lax, None | | Formulaire POST | \ | Non défini\*, None | | iframe | \ | Non défini\*, None | | AJAX | $.get("...") | Non défini\*, None | | Image | \ | NetSet\*, None | Tableau de [Invicti](https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/) et légèrement modifié.\ Un cookie avec l'attribut _**SameSite**_ **atténuera les attaques CSRF** où une session connectée est nécessaire. **\*Notez qu'à partir de Chrome80 (fév/2019), le comportement par défaut d'un cookie sans l'attribut samesite** **sera lax** ([https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/](https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/)).\ Notez que temporairement, après l'application de ce changement, les **cookies sans politique SameSite** dans Chrome seront **traités comme None** pendant les **2 premières minutes, puis comme Lax pour les demandes POST inter-sites de niveau supérieur.** ## Drapeaux des cookies ### HttpOnly Cela évite au **client** d'accéder au cookie (via **Javascript** par exemple : `document.cookie`) #### **Contournements** * Si la page envoie les cookies en tant que réponse d'une demande (par exemple dans une page **PHPinfo**), il est possible d'exploiter la XSS pour envoyer une demande à cette page et **voler les cookies** de la réponse (voir un exemple dans [https://hackcommander.github.io/pentesting-article-1/)](https://hackcommander.github.io/pentesting-article-1/) * Cela peut être contourné avec des demandes HTTP **TRACE** car la réponse du serveur (si cette méthode HTTP est disponible) reflétera les cookies envoyés. Cette technique s'appelle **Cross-Site Tracking**. * Cette technique est évitée par **les navigateurs modernes en n'autorisant pas l'envoi d'une demande TRACE** depuis JS. Cependant, certains contournements ont été trouvés dans des log ```js document.cookie = "a=v1" document.cookie = "=test value;" // empty name document.cookie = "b=v2" ``` Cela donne comme résultat l'en-tête de cookie envoyé : ``` a=v1; test value; b=v2; ``` Plus intéressant encore, si vous avez un vecteur qui vous permet d'une manière ou d'une autre de **définir le cookie vide**, vous pouvez **contrôler n'importe quel autre cookie** : ```js function setCookie(name, value) { document.cookie = `${name}=${value}`; } setCookie("", "a=b"); // this sets the empty cookie to a=b ``` Bien que, en interne dans le navigateur, cela soit défini comme un cookie nommé vide, cela se traduira par l'**en-tête de cookie envoyé :** ``` a=b; ``` Cela signifie que chaque serveur web l'interprétera comme si le cookie `a` était défini à la valeur `b`. ### Bug Chrome - corruption de document.cookie Si un point de code de substitution Unicode est présent dans un cookie défini, `document.cookie` sera corrompu de manière permanente et renverra une chaîne vide. ```js document.cookie // "a=b;" document.cookie = "\ud800=meep"; document.cookie // "" ``` ### Contrebande de cookies Plusieurs serveurs web, y compris les serveurs Java Jetty, TomCat, Undertow et le framework web Python Zope, ainsi que les serveurs/frameworks web Python tels que cherrypy, web.py, aiohttp server, bottle et webob, sont trouvés pour **analyser incorrectement les chaînes de cookies** en raison du support restant pour RFC2965, un mécanisme de citation de cookie obsolète qui utilise RFC2616 pour une définition de chaîne citée. Plus précisément, **ces serveurs continuent de lire une chaîne de cookies lorsqu'ils rencontrent une valeur de cookie entre guillemets doubles (dquoted), même s'ils rencontrent un point-virgule**. Cela pose problème car **les points-virgules sont censés séparer les paires clé-valeur** dans la chaîne de cookies. Par exemple, si un **navigateur envoie trois cookies, RENDER\_TEXT, JSESSIONID,** et **ASDF:** ```basic RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end"; ``` Ces serveurs les interprètent comme faisant partie d'une **seule valeur de cookie** plutôt que de trois cookies distincts. Cela entraîne un risque de sécurité : si un attaquant obtient un accès de script intersite (XSS), il peut utiliser cette faille pour **exfiltrer des cookies sensibles tels que les cookies HttpOnly**. ### Injection de cookie De nombreux serveurs Web, y compris Undertow de Java, Zope de Python et ceux utilisant http.cookie.SimpleCookie et http.cookie.BaseCookie de la bibliothèque standard de Python, ont été trouvés pour **analyser incorrectement les cookies, en utilisant de mauvais délimiteurs pour commencer la paire nom/valeur du cookie suivant**. Cela permet à un attaquant de **fausser plusieurs cookies tout en ne contrôlant qu'une seule valeur de cookie**. Dans le cas d'**Undertow**, il commence à analyser le cookie suivant immédiatement après la **fin d'une valeur de cookie entre guillemets**, sans attendre un point-virgule : ```bash LANGUAGE="en-us" CSRF_TOKEN="SPOOFED_VALUE" ``` **Zope** commence à analyser le cookie suivant sur une **virgule** : ```bash LANGUAGE=en-us,CSRF_TOKEN=SPOOFED_VALUE ``` Et **SimpleCookie** et **BaseCookie** de Python commencent immédiatement à analyser le cookie suivant sur un caractère **espace** : ``` LANGUAGE=en-us CSRF_TOKEN=SPOOFED_VALUE ``` En conséquence, des serveurs tels que **cherrypy**, **web.py**, le serveur **aiohttp**, **bottle** et **webob** (Pyramid, TurboGears) sont tous vulnérables à ce type d'attaque. Ce problème présente des **implications de sécurité** importantes. Par exemple, si une application Web utilise une protection CSRF basée sur les cookies, un attaquant peut **injecter** un **cookie de jeton CSRF falsifié** pour contourner cette protection. De plus, le dernier nom de cookie en double dans les packages http.cookie de Python remplace tous les précédents, rendant ce type d'attaque particulièrement facile. De plus, le **falsification** des cookies **`__Secure-`** et **`__Host-`** peut être exploitée dans un contexte non sécurisé. De plus, dans une configuration où les cookies sont transmis à un serveur backend, l'injection de cookies pourrait entraîner des contournements d'autorisation si le serveur backend est susceptible de falsification mais que le serveur frontend ne l'est pas. ### Vérifications supplémentaires des cookies vulnérables #### **Vérifications de base** * Le **cookie** est le **même** à chaque fois que vous **vous connectez**. * Déconnectez-vous et essayez d'utiliser le même cookie. * Essayez de vous connecter avec 2 appareils (ou navigateurs) sur le même compte en utilisant le même cookie. * Vérifiez si le cookie contient des informations et essayez de le modifier. * Essayez de créer plusieurs comptes avec des noms d'utilisateur presque identiques et vérifiez si vous pouvez voir des similitudes. * Vérifiez l'option "**se souvenir de moi**" si elle existe pour voir comment elle fonctionne. Si elle existe et qu'elle peut être vulnérable, utilisez toujours le cookie de **se souvenir de moi** sans aucun autre cookie. * Vérifiez si le cookie précédent fonctionne même après avoir changé le mot de passe. #### **Attaques de cookies avancées** Si le cookie reste le même (ou presque) lorsque vous vous connectez, cela signifie probablement que le cookie est lié à un champ de votre compte (probablement le nom d'utilisateur). Ensuite, vous pouvez : * Essayez de créer beaucoup de **comptes** avec des noms d'utilisateur très **similaires** et essayez de **deviner** comment fonctionne l'algorithme. * Essayez de **forcer le nom d'utilisateur**. Si le cookie ne sauvegarde que comme méthode d'authentification pour votre nom d'utilisateur, vous pouvez créer un compte avec le nom d'utilisateur "**Bmin**" et **forcer** chaque **bit** de votre cookie car l'un des cookies que vous essayerez sera celui appartenant à "**admin**". * Essayez **Padding** **Oracle** (vous pouvez décrypter le contenu du cookie). Utilisez **padbuster**. **Padding Oracle - Exemples de Padbuster** ```bash padbuster # When cookies and regular Base64 padbuster http://web.com/index.php u7bvLewln6PJPSAbMb5pFfnCHSEd6olf 8 -cookies auth=u7bvLewln6PJPSAbMb5pFfnCHSEd6olf # If Base64 urlsafe or hex-lowercase or hex-uppercase --encoding parameter is needed, for example: padBuster http://web.com/home.jsp?UID=7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 8 -encoding 2 ``` Padbuster effectuera plusieurs tentatives et vous demandera quelle condition est la condition d'erreur (celle qui n'est pas valide). Ensuite, il commencera à décrypter le cookie (cela peut prendre plusieurs minutes). Si l'attaque a réussi, vous pouvez essayer de crypter une chaîne de votre choix. Par exemple, si vous voulez **crypter** **user=administrateur**. ``` padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator ``` Cette exécution vous donnera le cookie correctement crypté et encodé avec la chaîne **user=administrator** à l'intérieur. **CBC-MAC** Il se peut qu'un cookie ait une certaine valeur et qu'il puisse être signé en utilisant CBC. Ensuite, l'intégrité de la valeur est la signature créée en utilisant CBC avec la même valeur. Comme il est recommandé d'utiliser un vecteur nul comme IV, ce type de vérification d'intégrité pourrait être vulnérable. **L'attaque** 1. Obtenir la signature de l'utilisateur **administ** = **t** 2. Obtenir la signature de l'utilisateur **rator\x00\x00\x00 XOR t** = **t'** 3. Définir dans le cookie la valeur **administrator+t'** (**t'** sera une signature valide de **(rator\x00\x00\x00 XOR t) XOR t** = **rator\x00\x00\x00** **ECB** Si le cookie est crypté en utilisant ECB, il pourrait être vulnérable.\ Lorsque vous vous connectez, le cookie que vous recevez doit être toujours le même. **Comment détecter et attaquer:** Créez 2 utilisateurs avec presque les mêmes données (nom d'utilisateur, mot de passe, e-mail, etc.) et essayez de découvrir un certain modèle à l'intérieur du cookie donné. Créez un utilisateur appelé, par exemple, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" et vérifiez s'il y a un modèle dans le cookie (comme ECB chiffre avec la même clé chaque bloc, les mêmes octets chiffrés pourraient apparaître si le nom d'utilisateur est chiffré). Il devrait y avoir un modèle (avec la taille d'un bloc utilisé). Ainsi, en sachant comment un tas de "a" est chiffré, vous pouvez créer un nom d'utilisateur: "a"\*(taille du bloc)+"admin". Ensuite, vous pouvez supprimer le modèle chiffré d'un bloc de "a" du cookie. Et vous aurez le cookie de l'utilisateur "admin". ## Références * [https://blog.ankursundara.com/cookie-bugs/](https://blog.ankursundara.com/cookie-bugs/)
☁️ 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**](https://discord.gg/hRep4RUj7f) 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).