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.
He could successfully “log in” the victim onto an arbitrary account, alter settings or even CSRF tokens.
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.
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.
And of course, don’t host applications with XSS. 🙂
Leave a Reply