4 KiB
Cookie Tossing
Description
If an attacker is able to control a subdomain of the domain of a company or finds a 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 in subdomains.
{% hint style="danger" %}
Therefore, an attacker is going to be able to set to the domain and subdomains an specific cookie doing something like document.cookie="session=1234; Path=/app/login; domain=.example.com"
{% endhint %}
This can be really dangerous as the attacker may be able to:
- Fixate the cookie of the victim to the attackers account so if the user doesn't notice, he will perform the actions in the attackers 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, wait until the victim logs in and then use that cookie to log in as the victim.
- 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).
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 web sites will only use the first value. Then, if an attacker wants to set a cookie it's better to set it before another one if 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
A 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 Tossin attack may be used also to perform 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"