Cross domain cookie contamination

TLDR: XSS attacks can be used to set cookies for sub domains that share the same top level domain. This increases the scope of XSS attacks.

In a cloud world; several applications are hosted under the same top level domain. An organization can have hostnames such as:

• company.com: corporate landing page
• mail.company.com: webmail
• intranet.company.com: internal resources .
• store.company.com: web store.
  

Since they all share the same top level domain, an XSS vulnerability could help an setting domain wide cookies. Domain-wide cookies are inherited by all sub domains, so it could contaminate cookie values of other sub domains.

The “attack”

There are two main scenarios, both using vuln.domain.com, which has an exploitable XSS attack, and intranet.domain.com, which uses cookies for session management. An attacker exploits a victim using the XSS vuln, but instead of doing the obvious cookie stealing or DOM manipulation (on vuln.domain.com), he can set arbitrary cookies for the entire domain; including intranet.domain.com. If he’d execute something like:

domain.cookie="sessionid=attackersessionid; domain=domain.com;";
domain.cookie="csrftoken=a1b2c3d4; domain=domain.com;";

He could successfully “log in” the victim onto an arbitrary account, alter settings or even CSRF tokens.

Caveats

If a host, such as intranet.domain.com has a cookie set already, the browser (FF under u18.04 at least, testing others) will present both cookies. I’m currently figuring out what different frameworks to when several cookies are presented with the same name.

This may prove for interesting attacks, especially for applications that are hosted on a “more critical” top level domain, or are “shared” across cloud providers.

Remedation

Not a fool proof solution, but you probably want to move away from storing values in cookies that can dictate a particular state, unless it can be validated (signature, …), or host applications of different “value” off different top level domains.

If you have a JavaScript rich application, and you handle authentication (api calls, etc) with tokens that you store in cookies; you may want to opt for localStorage or sessionStorage, rather than HTTP cookies.

And of course, don’t host applications with XSS. 🙂