CORS, SOP & crossdomain.xml For Dummies

Reading time ~2 minutes

Things were really simple when webpages were static. Write some text, add images, add links and serve it to your users.
Then JavaScript came into existence and it made webpages dynamic. Now webpages had animations, cool drop down menus and shit, now they could even make request to some other webpage without user interaction. Yeah that’s fun but then some smart ass guy thought what if we use JavaScript on to steal data from where user is logged in. Now you know where that “Cross” in Cross Site Scripting came from.

Same Origin Policy

Well then some other smart ass proposed that we should setup a restriction on these cross domain requests on the browser level. He said we will call it Same Origin Policy and it won’t let JavaScript make request to a webpage which isn’t hosted on the same domain. Here’s how it works Ayy bruh! Can I fetch light.json from real quick?

we don't do that here meme

Now lets see which pages can be accessed by

Resource Result Reason Successs Same Host, Port, Protocol Failure Different Host Failure Different Host Failure Different Protocol Failure Different Port

Cross Origin Resource Sharing

Things were secure again but it raised a problem, a big one. This restriction was applied to stop bad guys for making cross domain requests but it was no longer possible to make requests from to
To make things good again, they introduced something called Cross Origin Resource Sharing. The idea was simple, let developers choose whom they want to share their resources with. If the developers wants share data between and, let him do so.
For this purpose, he will need to setup a new header on as follows:


That’s it!

How CORS works?

Step 1. You visit in your browser
Step 2. The website tries to load data from
Step 3. Your browser makes a request to
Step 4. returns the response including the following HTTP header:


Step 5. Browser checks if is allowed
Step 6. Yes it is, the response now can be used by the JavaScript


Unfortunately, JavaScript isn’t the only technology which needs to make cross domain requests within a browser. There are some web clients such as adobe flash which need to do the same. So these clients posed a security issue too.

A guy suggested to standardize another header with the name
He was beaten up by asians because the header name was too long ;)

Well, instead of using a seperate header this time, they decide to use a file named crossdomain.xml which should be located in root of the host just like robots.txt

Here’s for example:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "">
	<site-control permitted-cross-domain-policies="master-only" />
	<allow-access-from domain="" />
	<allow-access-from domain="" />
	<allow-access-from domain="" />
	<allow-access-from domain="" />
	<allow-access-from domain="" />
	<allow-access-from domain="" />
	<allow-access-from domain="" />
	<allow-access-from domain="" />
	<allow-access-from domain="" />
	<allow-access-from domain="" />
	<allow-access-from domain="static.xx.fbcdn23dssr3jqnq.testonion" />
	<allow-access-from domain="static.xx.fbcdn23dssr3jqnq.onion" />
	<allow-access-from domain="" />

It’s similar to the Access-Control-Allow-Origin, when a web client is running in your browser and it tries to make request to some another domain, your browser checks if that domain’s crossdomain.xml specification allows that.

So yeah, that’s pretty much it.
Also, Marvel is better than DC.

From XSS to RCE

I managed to executed system commands with XSS. Continue reading

Mass Cracking Cybrary Accounts

Published on February 06, 2019

21 things you can do with XSS

Published on January 04, 2019