Cookie Tossing

Reading time: 5 minutes

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)

Soutenir HackTricks

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 donc 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...)
  • 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 faire en sorte que l'utilisateur effectue 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.

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é de 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 défini 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.

Cookie Jar Overflow

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.

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

Cookie Bomb

Defenses

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

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)

Soutenir HackTricks