Cookie Tossing

web security

Definition

Cookie Tossing

Cookie tossing is an attack where a same-site attacker uses a subdomain such as evil.bank.com to set a Domain=bank.com cookie that shadows the victim’s session cookie on bank.com. When the victim requests /account/, the browser sends the attacker’s cookie first; the session id it names is now the attacker’s, so the victim is logged in as the attacker — a session swapping that lets the attacker track or manipulate the victim’s activity.

Why Browsers Let This Happen

Obs

The browser keys cookies by $⟨\text{name},\text{domain},\text{path}⟩$, but the Cookie request header sends only name/value pairs. The server therefore has no way to tell which cookie is for which domain or path, and most servers accept the first matching one. Most browsers order cookies oldest first, and put longer (more specific) paths first — so a path=/account cookie planted from a subdomain wins over the genuine path=/ cookie.

Defence

Defence: cookie prefixes

A cookie named __Host-sid is accepted only if it is Secure, comes from a secure origin, has no Domain attribute, and sets Path=/ — i.e. it is host-locked. The __Secure- prefix is the weaker variant that merely pins HTTPS. See Cookie Prefix.

Example

Tossing the victim into the attacker's session

The attacker controls evil.bank.com (a same-site attacker). Crucially, a subdomain may set a cookie with Domain=bank.com, so the browser stores that cookie as scoped to the whole of bank.com, not just to evil.bank.com — that is the legitimate relaxation domain cookies afford, and exactly the lever the attack pulls.

1. The attacker logs in to bank.com themselves and receives a real, valid session id s_atk for their own account.
2. From evil.bank.com the attacker runs Set-Cookie: SESSID=s_atk; domain=bank.com; path=/account/. Because domain=bank.com, the browser places this cookie in bank.com’s jar, with path=/account/.
3. The victim logs in to bank.com and gets Set-Cookie: SESSID=s_bob; path=/ — the genuine session id, host-locked on bank.com.
4. The victim requests GET /account/index.html. Both cookies match the URL, so the browser sends both name/value pairs: Cookie: SESSID=s_atk; SESSID=s_bob. It puts the more-specific-path cookie (/account/, the planted one) first.
5. The server, seeing two SESSID values and the application convention of taking the first, authenticates the request as s_atk — i.e. as the attacker. The page prints Welcome, Attacker!.

The victim is now operating inside the attacker’s session, so any activity the victim performs on /account/ (pages viewed, searches, data entered believing it is their own session) is visible to the attacker, who knows s_atk because it is theirs. This is the “session swapping” the slide name refers to — the victim is swapped into the attacker’s session, not the other way round.

The whole trick lives in the jar’s ordering rule, not in anything the server does wrong: two same-named cookies both legitimately match the request, and the browser’s most-specific-path-first rule happens to put the subdomain-planted one on top. A [[Knowledge/Cookie Prefix|__Host- prefix]] removes the lever by forbidding the Domain attribute and pinning Path=/, so a subdomain simply cannot plant a host-locked cookie to compete with the genuine one.