Notes on "Subdomain Takeover: Ignore This Vulnerability at Your Peril"

Notes on Subdomain Takeover: Ignore This Vulnerability at Your Peril

This article describes what are the implications if an attacker gets access to a subdomain, such as product1.example.com.

How can that happen? For example, you start using a service (example-dot-org.tiptopapp.com is the example in the article), set up a CNAME (tiptop.example.com) then cancel the service. Now someone else can register the same account and then they have full control over the tiptop.example.com subdomain.

Another scenario is when different products are managed by different teams (product1.example.com, product2.example.com) and some are protected less than others. A breach in one can affect the security of the others.

The article discusses several implications, but the most surprising for me is CSRF.

Cookies have a SameSite attribute that is supposedly prevent the browser from sending them when a request is made cross-site. The problem is that it's cross-site and not cross-origin. example.com is the same site as product2.example.com so when the victim goes to product2.example.com and sends a request to example.com even the SameSite: Strict cookies will be sent!

Unless the server at example.com makes other checks, that means a subdomain takeover opens up CSRF attacks.

How to defend against this?

I'm currently looking into the Sec-Fetch-Site header the browser sends (more info here). With this, the server can protect itself from cross-origin (but same-site) requests.