Escalating subdomain takeovers to steal cookies by abusing document.domain

Hi everyone,

It's been a really long time since I've blogged about anything. Mainly because I got a job as security analyst- therefore I've been very busy. And I also got into Synack!

This blog post focuses on one of my recent findings, how I was able to escalate an out of scope subdomain takeover to steal the session cookies. And how I also thought of a few more methods to escalate it, affecting the main domain.

Before I get started with the bug, I would like to talk a little about same-origin policy. If 2 websites want to communicate with each other, or perhaps if 2 hosts want to interact with each other, there could be mainly 2 ways to go around this. The book "Tangled Web" (a great book, do read it) states the following:

"Attempts to broaden origins or facilitate cross-domain interactions are more common. The two broadly sup- ported ways of achieving these goals are document.domain and postMessage(...)"


This JavaScript property permits any two cooperating websites that share a common top-level domain (such as, or even just .com) to agree that for the purpose of future same-origin checks, they want to be considered equivalent.

So basically, if and both explicitly set their document.domain to, this will lax the same-origin policy checks thereafter.


I was hunting on the Postmates bug bounty program from H1. Now this program has a limited scope. I came across an [[in-scope]] endpoint like the following:

Now this endpoint was only was only accepting image links coming from subdomains of I thought, if somehow I can find a subdomain takeover, maybe I can find an SSRF or perhaps serve my own malicious content to the victim. So I went ahead and fired up some subdomain discovery tools and started sifting through them. I found one subdomain,, which was prone to a Github subdomain takeover. I went ahead and added the custom domain name to my test repo and the subdomain was mine.

However, I couldn't have access to any backend, so an SSRF was impossible in this case. The max I could do was serve random JPEG's. Bummer.

After a lot of time of thinking, something struck my mind. The main domain for users in Postmates is,

Now, "Tangled Web" also states:

"Simply because has set its document.domain to does not mean that it will be allowed to access content originating from the website hosted at That website needs to perform such an assignment, too, even if common sense would indicate that it is a no-op."

So, if and only if, has explicitly set it's document.domain, maybe I could set's document.domain to and access it's cookies somehow?

Precursor: can NOT set it's document.domain to or, but it CAN set it's document.domain to An example of changing the values of to other settings:
That being said, I went ahead to check if had explicitly set their document.domain. They had! Now, you have to keep in mind, that this attack worked only because the main domain of the program was (that is, document.domain = and not something like (document.domain possibly set to, because then I could not set the document.domain of to So now all I had to do was, using JS, set the document.domain to, and add the following code in my javascript to steal the cookies from the main account:
That's it, I could alert the cookies of now, and possibly perform an account takeover, since I had complete access to the DOM of the main website.
While working on this, I even thought of a few other creative ways to escalate an subdomain takeover to increase it's impact:

  • Bypassing X-Frame-Options : SAMEORIGIN
  • Bypassing CORS validation where the Access-Control-Allow-Origin is set to * (* being any subdomain)
  • Bypassing URL validation wherever applicable (eg. open redirects to steal OAuth login tokens etc.


Popular Posts