Cookie Tossing

Reading time: 5 minutes

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.

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"

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.

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.

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.

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.

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.

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

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"

The browsers have a limit on the number of cookies that they can store for a page. Then, if for some reason you need to make a cookie disappear, you can overflow the cookie jar as the oldest ones will be deleted before:

javascript

// Set many cookies
for (let i = 0; i < 700; i++) {
  document.cookie = `cookie${i}=${i}; Secure`
}

// Remove all cookies
for (let i = 0; i < 700; i++) {
  document.cookie = `cookie${i}=${i};expires=Thu, 01 Jan 1970 00:00:01 GMT`
}

Notice, that third party cookies pointing to a different domain won't be overwritten.

❗ This attack can also be used to overwrite HttpOnly cookies as you can delete it and then reset it with the value you want. ❗

Cookie bomb involves adding a significant number of large cookies to a domain and its subdomains targeting a user. This action results in the victim sending oversized HTTP requests to the server, which are subsequently rejected by the server. The consequence of this is the induction of a Denial of Service (DoS) specifically targeted at a user within that domain and its subdomains.

PreviousCookies Hacking NextCORS - Misconfigurations & Bypass

Last updated 3 months ago

Reading time: 5 minutes

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.

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"

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.