mirror of https://github.com/carlospolop/hacktricks synced 2024-11-27 07:01:09 +00:00

History

Translator c905035a52 Translated ['pentesting-web/hacking-with-cookies/cookie-bomb.md', 'pente		2024-01-10 17:09:46 +00:00
..
cookie-bomb.md	Translated ['pentesting-web/hacking-with-cookies/cookie-bomb.md', 'pente	2024-01-10 17:09:46 +00:00
cookie-jar-overflow.md	Translated ['pentesting-web/hacking-with-cookies/cookie-bomb.md', 'pente	2024-01-10 17:09:46 +00:00
cookie-tossing.md	Translated ['pentesting-web/hacking-with-cookies/cookie-bomb.md', 'pente	2024-01-10 17:09:46 +00:00
README.md	Translated ['pentesting-web/deserialization/nodejs-proto-prototype-pollu	2024-01-01 18:37:39 +00:00

README.md

Piratage de Cookies

Apprenez le piratage AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres moyens de soutenir HackTricks :

Si vous souhaitez voir votre entreprise annoncée dans HackTricks ou télécharger HackTricks en PDF, consultez les PLANS D'ABONNEMENT!
Obtenez le merchandising officiel PEASS & HackTricks
Découvrez La Famille PEASS, notre collection d'NFTs exclusifs
Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez moi sur Twitter 🐦 @carlospolopm.
Partagez vos astuces de piratage en soumettant des PR aux dépôts github HackTricks et HackTricks Cloud.

Trouvez les vulnérabilités les plus importantes pour les corriger plus rapidement. Intruder suit votre surface d'attaque, effectue des analyses de menaces proactives, trouve des problèmes dans l'ensemble de votre pile technologique, des API aux applications web et aux systèmes cloud. Essayez-le gratuitement aujourd'hui.

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}

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 avant la suppression d'un cookie (utilisez ceci, nous ne sommes plus en 2009)

Domain

L'attribut Domain spécifie quels hôtes peuvent recevoir un cookie. S'il n'est pas spécifié, l'attribut prend par défaut 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 de l'omettre. 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 comme 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 un attribut domain de .example.com, il sera envoyé lors des requêtes au domaine parent.

Path

L'attribut Path indique un chemin 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é depuis d'autres domaines. Il a 3 valeurs possibles :

Strict : Le cookie ne sera pas envoyé avec une requête par des sites tiers.
Lax : Le cookie sera envoyé avec la requête GET initiée par des sites tiers.
None : Le cookie est envoyé de n'importe quel domaine tiers

Type de Requête	Code Exemple	Cookies Envoyés Quand
Lien	<a href="..."></a>	NotSet*, Lax, None
Prerender	<link rel="prerender" href=".."/>	NotSet*, Lax, None
Form GET	<form method="GET" action="...">	NotSet*, Lax, None
Form POST	<form method="POST" action="...">	NotSet*, None
iframe	<iframe src="..."></iframe>	NotSet*, None
AJAX	$.get("...")	NotSet*, None
Image	<img src="...">	NetSet*, None

Tableau de Invicti et légèrement modifié.
Un cookie avec l'attribut SameSite atténuera les attaques CSRF où une session connectée est nécessaire.

*Remarquez qu'à partir de Chrome80 (fév/2019) le comportement par défaut d'un cookie sans attribut samesite sera lax (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 premières 2 minutes puis comme Lax pour les requêtes POST inter-sites de niveau supérieur.

Drapeaux des Cookies

HttpOnly

Cela empêche le client d'accéder au cookie (Via Javascript par exemple : document.cookie)

Contournements

Si la page envoie les cookies comme réponse à une requête (par exemple sur une page PHPinfo), il est possible d'abuser du XSS pour envoyer une requête à cette page et voler les cookies de la réponse (consultez un exemple sur https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/.
Cela pourrait être contourné avec des requêtes HTTP TRACE car la réponse du serveur (si cette méthode HTTP est disponible) reflétera les cookies envoyés. Cette technique est appelée Cross-Site Tracking.
Cette technique est évitée par les navigateurs modernes en ne permettant pas l'envoi d'une requête TRACE depuis JS. Cependant, certains contournements ont été trouvés dans des logiciels spécifiques comme l'envoi de \r\nTRACE au lieu de TRACE à IE6.0 SP2.
Une autre façon est l'exploitation de vulnérabilités zero/day des navigateurs.
Il est possible de réécrire des cookies HttpOnly en effectuant une attaque par débordement de Cookie Jar :

{% content-ref url="cookie-jar-overflow.md" %} cookie-jar-overflow.md {% endcontent-ref %}

Il est possible d'utiliser l'attaque Cookie Smuggling pour exfiltrer ces cookies

Secure

La requête n'envoie le cookie dans une requête HTTP que si la requête est transmise sur un canal sécurisé (typiquement HTTPS).

Préfixes des Cookies

Préfixe __Secure- : doit être défini avec le drapeau secure à partir d'une page sécurisée (HTTPS).

Préfixe __Host- : doit être défini avec le drapeau secure, doit provenir d'une page sécurisée (HTTPS), ne doit pas avoir de domaine spécifié (et donc, n'est pas envoyé aux sous-domaines), et le chemin doit être /.

Les cookies préfixés par __Host- ne peuvent pas être envoyés aux superdomaines (cookies des sous-domaines vers les domaines) ou aux sous-domaines (cookies des domaines vers les sous-domaines), donc, si vous voulez isoler les cookies de votre application, les préfixer tous avec __Host- n'est pas une mauvaise idée.

Attaques sur les Cookies

Si vous trouvez un type de cookie personnalisé contenant des données sensibles (sessionID, nom d'utilisateur, emails, etc.), vous devriez absolument essayer de l'exploiter

Si le cookie utilise un encodage de base (comme Base64) ou similaire, vous pourriez être capable de le décoder, changer le contenu et usurper des utilisateurs arbitraires.

Détournement de session

Voler un cookie et l'utiliser pour usurper l'identité de l'utilisateur au sein d'une application

Fixation de session

L'attaquant obtient un cookie d'une page web et envoie un lien à la victime pour se connecter en utilisant le même cookie. Si le cookie n'est pas changé lorsqu'un utilisateur se connecte, cela pourrait être utile car l'attaquant pourrait être capable d'usurper l'utilisateur à travers un cookie.

Si vous avez trouvé un XSS dans un sous-domaine ou si vous contrôlez un sous-domaine, lisez :

{% content-ref url="cookie-tossing.md" %} cookie-tossing.md {% endcontent-ref %}

Donation de session

L'attaquant envoie sa propre session à la victime. La victime verra qu'elle est déjà connectée et supposera qu'elle est dans son compte mais les actions seront effectuées dans le compte de l'attaquant.

Si vous avez trouvé un XSS dans un sous-domaine ou si vous contrôlez un sous-domaine, lisez :

{% content-ref url="cookie-tossing.md" %} cookie-tossing.md {% endcontent-ref %}

Cliquez sur le lien précédent pour accéder à une page expliquant les failles possibles dans les JWT.

Les navigateurs permettent un cookie avec un nom vide

document.cookie = "a=v1"
document.cookie = "=test value;" // empty name
document.cookie = "b=v2"

Cela entraîne l'envoi de l'en-tête de cookie :

a=v1; test value; b=v2;

Plus intéressant encore, si vous disposez d'un vecteur qui vous permet de définir le cookie vide, vous pouvez contrôler tout autre cookie :

function setCookie(name, value) {
document.cookie = `${name}=${value}`;
}

setCookie("", "a=b"); // this sets the empty cookie to a=b

Bien que, dans le navigateur, cela soit défini comme le cookie nommé vide, cela entraînera l'en-tête de cookie envoyé :

a=b;

Cela signifie que chaque serveur web l'interprétera comme le cookie a étant défini avec la valeur b.

Si un point de code substitut Unicode est présent dans un cookie défini, document.cookie sera définitivement corrompu et renverra une chaîne vide.

document.cookie
// "a=b;"
document.cookie = "\ud800=meep";
document.cookie
// ""

Plusieurs serveurs web, y compris les serveurs Java Jetty, TomCat, Undertow, et le framework web Python Zope, ainsi que des serveurs/frameworks web Python comme cherrypy, web.py, aiohttp server, bottle, et webob, se sont avérés analyser incorrectement les chaînes de cookies en raison du support résiduel pour RFC2965, un mécanisme de citation de cookies obsolète qui utilise RFC2616 pour une définition de chaîne entre guillemets.

Plus précisément, ces serveurs continuent de lire une chaîne de cookie lorsqu'ils rencontrent une valeur de cookie entre guillemets doubles (dquoted), même si un point-virgule est rencontré. Cela pose problème car les points-virgules sont censés séparer les paires clé-valeur dans la chaîne de cookie.

Par exemple, si un navigateur envoie trois cookies, RENDER_TEXT, JSESSIONID, et ASDF :

RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";

ces serveurs les interprètent comme faisant partie d'une valeur de cookie unique plutôt que de trois cookies séparés.

Cela conduit à un risque de sécurité : si un attaquant obtient un accès de type cross-site scripting (XSS), il peut utiliser ce bug pour exfiltrer des cookies sensibles comme les cookies HttpOnly.

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 simuler plusieurs cookies tout en ne contrôlant qu'une seule valeur de cookie.

Dans le cas d'Undertow, il commence l'analyse du cookie suivant immédiatement après la fin d'une valeur de cookie entre guillemets, sans attendre de point-virgule :

LANGUAGE="en-us" CSRF_TOKEN="SPOOFED_VALUE"

Zope commence l'analyse du cookie suivant sur une virgule :

LANGUAGE=en-us,CSRF_TOKEN=SPOOFED_VALUE

Et Python's SimpleCookie et BaseCookie commencent immédiatement à analyser le prochain cookie sur un caractère espace :

LANGUAGE=en-us CSRF_TOKEN=SPOOFED_VALUE

En conséquence, les serveurs tels que cherrypy, web.py, aiohttp server, bottle et webob (Pyramid, TurboGears) sont tous vulnérables à ce type d'attaque.

Ce problème présente des implications de sécurité significatives. 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 paquets http.cookie de Python remplace tous les précédents, rendant ce type d'attaque particulièrement facile.

De plus, le spoofing des cookies __Secure- et __Host- peut être abusé dans un contexte non sécurisé. Aussi, dans une configuration où les cookies sont transmis à un serveur backend, l'injection de cookies pourrait conduire à des contournements d'autorisation si le serveur backend est sensible au spoofing mais pas le serveur frontend.

Vérifications supplémentaires des cookies vulnérables

Vérifications de base

Le cookie est identique à 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 pourrait ê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 avancées sur les cookies

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). Alors 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 brutalement le nom d'utilisateur. Si le cookie sert uniquement de méthode d'authentification pour votre nom d'utilisateur, alors vous pouvez créer un compte avec le nom d'utilisateur "Bmin" et forcer brutalement chaque bit de votre cookie car l'un des cookies que vous essayerez sera celui appartenant à "admin".
Essayez Padding Oracle (vous pouvez déchiffrer le contenu du cookie). Utilisez padbuster.

Padding Oracle - Exemples avec Padbuster

padbuster <URL/path/when/successfully/login/with/cookie> <COOKIE> <PAD[8-16]>
# 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échiffrer le cookie (cela peut prendre plusieurs minutes)

Si l'attaque a été réalisée avec succès, alors vous pourriez essayer de chiffrer une chaîne de votre choix. Par exemple, si vous vouliez chiffrer user=administrator

padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator

Cette exécution vous donnera le cookie correctement chiffré et encodé avec la chaîne user=administrator à l'intérieur.

CBC-MAC

Il se peut qu'un cookie ait une certaine valeur et soit 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 comme IV un vecteur nul, ce type de vérification d'intégrité pourrait être vulnérable.

L'attaque

Obtenez la signature du nom d'utilisateur administ = t
Obtenez la signature du nom d'utilisateur rator\x00\x00\x00 XOR t = t'
Définissez 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 chiffré en utilisant ECB, il pourrait être vulnérable.
Lorsque vous vous connectez, le cookie que vous recevez doit toujours être le même.

Comment détecter et attaquer :

Créez 2 utilisateurs avec des données presque identiques (nom d'utilisateur, mot de passe, email, etc.) et essayez de découvrir un motif à l'intérieur du cookie donné

Créez un utilisateur appelé par exemple "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" et vérifiez s'il y a un motif 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 motif (de la taille d'un bloc utilisé). Ainsi, sachant comment un tas de "a" est chiffré, vous pouvez créer un nom d'utilisateur : "a"*(taille du bloc)+"admin". Ensuite, vous pourriez supprimer le motif chiffré d'un bloc de "a" du cookie. Et vous aurez le cookie du nom d'utilisateur "admin".

Références

https://blog.ankursundara.com/cookie-bugs/

Trouvez les vulnérabilités qui comptent le plus afin de les corriger plus rapidement. Intruder suit votre surface d'attaque, lance des scans de menaces proactifs, trouve des problèmes dans l'ensemble de votre pile technologique, des API aux applications web et aux systèmes cloud. Essayez-le gratuitement aujourd'hui.