DΛΣMӨП

// HackTricks · Web Pentesting

Cookie Tossing

Cookie Tossing

Description

If an attacker controls a subdomain (or finds an XSS in one), they may be able to set a cookie whose Domain attribute covers the parent domain. A host may only set a Domain cookie for itself or a parent domain, never for an unrelated domain.[1]

The original attack notes on this page credit security researcher @blueminimal.[7]

A cookie with a Domain attribute is sent to that domain and its subdomains; omitting Domain creates a host-only cookie.[1]

[!CAUTION] 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 because the attacker may be able to:[2]

A conference presentation demonstrates additional session-integrity variants and is useful as a visual walkthrough of the attack family.[6]

  • Fix the victim’s cookie to the attacker’s account. If the victim does not notice, they may perform searches, add payment details, or enter other information into the attacker’s account, where the attacker can retrieve it.
    • In one documented OAuth example, a malicious cookie scoped to selected authorization endpoints caused the victim to authorize access under the attacker’s session.[3]
  • If the cookie does not change after login, the attacker may fixate a session cookie, wait until the victim logs in, and then reuse that cookie as the victim.
    • In some flawed renewal flows, presenting the pre-login cookie can also disclose or recover the renewed session.
  • If the cookie initializes state that survives login (for example, a CSRF token), the attacker may set a known value and later forge a request using that known 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.

RFC 6265 orders matching cookies by descending path length and then by ascending creation time, although servers should not rely on this serialization order. A request can therefore contain Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;.[1]

Many server frameworks select one of the duplicate values. An attacker therefore tries to make the malicious cookie the value selected by the target stack, commonly by setting it earlier or with a more specific path.[4]

[!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.

Protection Bypass

A possible protection is for the server to reject requests containing two cookies with the same name but different values.[2]

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.

Cookie Jar Overflow

Another useful bypass is to URL-encode the cookie name when a front-end protection compares raw names but the back end decodes them.[2]

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

Cookie Bomb

Defenses

Use the __Host- cookie-name prefix

  • A supporting user agent accepts a __Host- cookie only when it is set from a secure origin with Secure, has Path=/, and omits Domain.
  • This makes the cookie host-only and prevents a subdomain from creating that cookie for the parent domain.[5]

References