Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-15 01:17:36 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/hacking-with-cookies/cookie-tossing.md
Carlos Polop 0a6f574adb a
2024-07-19 16:09:38 +02:00

6.6 KiB
Raw Blame History

Cookie Tossing

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}

Description

If an attacker can control a subdomain or the domain of a company or finds an XSS in a subdomain he will be able to perform this attack.

As it was indicated in the Cookies Hacking section, when a cookie is set to a domain (specifying it) it will be used in the domain and subdomains.

{% hint style="danger" %} Therefore, an attacker is going to be able to set to the domain and subdomains a specific cookie doing something like document.cookie="session=1234; Path=/app/login; domain=.example.com" {% endhint %}

This can be dangerous as the attacker may be able to:

  • Fixate the cookie of the victim to the attacker's account so if the user doesn't notice, he will perform the actions in the attacker's account and the attacker may obtain some interesting information (check the history of the searches of the user in the platform, the victim may set his credit card in the account...)
  • If the cookie doesn't change after login, the attacker may just fixate a cookie (session-fixation), wait until the victim logs in and then use that cookie to log in as the victim.
    • Sometimes, even if the session cookies changes, the attacker use the previous one and he will receive the new one also.
  • If the cookie is setting some initial value (like in flask where the cookie may set the CSRF token of the session and this value will be maintained after the victim logs in), the attacker may set this known value and then abuse it (in that scenario, the attacker may then make the user perform a CSRF request as he knows the CSRF token).
    • Just like setting the value, the attacker could also get an unauthenticated cookie generated by the server, get the CSRF token from it and use it.

Cookie Order

When a browser receives two cookies with the same name partially affecting the same scope (domain, subdomains and path), the browser will send both values of the cookie when both are valid for the request.

Depending on who has the most specific path or which one is the oldest one, the browser will set the value of the cookie first and then the value of the other one like in: Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;

Most websites will only use the first value. Then, if an attacker wants to set a cookie it's better to set it before another one is set or set it with a more specific path.

{% hint style="warning" %} Moreover, the capability to set a cookie in a more specific path is very interesting as you will be able to make the victim work with his cookie except in the specific path where the malicious cookie set will be sent before. {% endhint %}

Protection Bypass

Possible protection against this attack would be that the web server won't accept requests with two cookies with the same name but two different values.

To bypass the scenario where the attacker is setting a cookie after the victim was already given the cookie, the attacker could cause a cookie overflow and then, once the legit cookie is deleted, set the malicious one.

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

Another useful bypass could be to URL encode the name of the cookie as some protections check for 2 cookies with the same name in a request and then the server will decode the names of the cookies.

Cookie Bomb

A Cookie Tossing attack may also be used to perform a Cookie Bomb attack:

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

Defenses

Use the prefix __Host in the cookie name

  • If a cookie name has this prefix, it will only be accepted in a Set-Cookie directive if it is marked Secure, was sent from a secure origin, does not include a Domain attribute, and has the Path attribute set to /
  • This prevents subdomains from forcing a cookie to the apex domain since these cookies can be seen as "domain-locked"

References

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}