Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 13:13:41 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/hacking-with-cookies/cookie-tossing.md
Translator workflow af42105553 Translated to French
2023-06-03 13:10:46 +00:00

6.1 KiB
Raw Blame History

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

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 {% 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 {% 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