Cookie Tossing
Description
Si un attaquant peut contrôler un sous-domaine ou le domaine d'une entreprise ou trouve une XSS dans un sous-domaine, il pourra 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.
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 :
Fixer le cookie de la victime sur le compte de l'attaquant donc si l'utilisateur ne le 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 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 (fixation de session), attendre que la victime se connecte, puis utiliser ce cookie pour se connecter en tant que victime.
Parfois, même si les cookies de session changent, l'attaquant peut utiliser l'ancien et recevra également le nouveau.
Si le cookie définit une valeur initiale (comme dans Flask où le cookie peut définir le jeton CSRF de la session et que cette valeur sera maintenue après la connexion de la victime), l'attaquant peut définir cette valeur connue puis l'exploiter (dans ce scénario, l'attaquant peut ensuite amener l'utilisateur à effectuer une requête CSRF car il connaît le jeton CSRF).
Tout comme définir la valeur, l'attaquant pourrait également obtenir un cookie non authentifié généré par le serveur, obtenir le jeton CSRF à partir de celui-ci et l'utiliser.
Ordre des cookies
Lorsqu'un navigateur reçoit deux cookies avec le même nom affectant partiellement le même champ d'application (domaine, sous-domaines et chemin), le navigateur enverra les deux valeurs du cookie lorsque les deux sont valides pour la requête.
En fonction de 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=CookiePlusSpécifiqueEtPlusAncien; iduser=MoinsSpécifique;
La plupart des sites Web n'utiliseront que la première valeur. Ainsi, si un attaquant souhaite 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.
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 défini sera envoyé en premier.
Contournement de la protection
Une protection possible contre cette attaque serait que le serveur Web n'accepte pas les requêtes avec deux cookies portant 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.
Un autre contournement utile pourrait être de coder en URL le nom du cookie car certaines protections vérifient la présence de 2 cookies portant le même nom dans une requête, puis le serveur décoderait les noms des cookies.
Bombe à cookies
Une attaque de Cookie Tossing peut également être utilisée pour effectuer une attaque de Bombe à cookies :
Défenses
Utilisez le préfixe __Host dans le nom du cookie
__Host dans le nom du cookieSi un nom de cookie a ce préfixe, il ne sera accepté que dans une directive Set-Cookie s'il est marqué comme sécurisé, 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 sur le domaine principal car ces cookies peuvent être considérés comme "verrouillés sur le domaine"
Références
Last updated