Hacking — Always Check the Cross-domain Policy

Mar 19, 2020 · 2 min read
Twitter is a good example of a secure cross-domain policy

Concise tip: When testing a new target, always check their cross-domain policy, usually located at /crossdomain.xml! If you can find a subdomain/DNS takeover in a site within <allow-access-from> in that policy, you’ve just bypassed Same Origin Policy and may be in for a big bounty.

My report: https://hackerone.com/reports/244504

One big thing to note is that if their policy is <allow-access-from domain=”*” />, they likely have other securities in place preventing CSRF/SOP bypass and this is not relevant.

Full story: When I began penetration testing, one approach I took was generally checking out configurations. I learned about a file on the root directory of many websites called crossdomain.xml. Any domains contained within <allow-access-from> tags in this policy can use flash files to access resources that are typically only accessible by the origin site. For example, see Twitter’s cross-domain policy. As you can see, they only allow access to these resources from *.twitter.com domains because resources like session cookies should not be shared with any other websites or the victim’s account could be compromised simply using CSRF.

In Starbuck’s case, they had many different domains in this file, one of them being *.example.com (we’ll say for confidentiality’s sake; this is an irrelevant detail anyway). I found that I could takeover a subdomain of example.com. Bingo — now I have ownership of a subdomain within Starbuck’s cross-domain policy! From here as an attacker you would need to perform CSRF in order to retrieve sensitive data like session cookies; this would involve making a flash file that just sent an HTTP request to a domain with the sensitive information stored on it and then logging the response which would contain all of the sensitive cookies due to the domain being included in the cross-domain policy.

To be entirely honest, when I found this in Starbucks, all I knew was that it was a configuration problem and I did not understand any of the technicalities behind it. I appreciate the Starbucks team being so open to my rather clueless self, and I learned more thoroughly after reporting it. In conclusion, always check the cross-domain policies of targets, because if they contain a wildcard for a domain with a subdomain takeover (and it’s not just a full wildcard * for any domain), they are likely in trouble.

The Volatile Triad

Hacking, biking, running and various other random things.