An overly permissive crossdomain.xml file on a domain that serves sensitive content is a major security risk. It exposes the domain hosting the improperly configured crossomain.xml file to information disclosure and request forgery. Attackers cannot only forge requests, they can read responses. This means the attacker can retrieve any information the authenticated user has access to, including account information, documents and files, and anti-CSRF tokens if they are used.


This is an old vulnerability. How old? 8 years old. Here is very rough outline of prior research/public discussion:

2006: Chris ShiflettJulien Couvreur, and Jeremiah Grossman started talking about this publicly.
2008: Jeremiah Grossman revisited the issue.
2010: Erlend Ofedel wrote about it, and  Mike Bailey gave talk at Blackhat DC.
2011: Teams from FORTH-ICSSAP Research, and UC San Diego all released research directly related to crossdomain.xml and the security risks that result from misconfiguration.

While there have been people in the know about this vulnerability since 2006, and some really great research published in 2011, this vulnerability has never really gained much traction.

Here are some Google search results, as of March 2014:

Search Term Result
“crossdomain.xml exploit” 34 unique hits
“crossdomain.xml attack” 26 unique hits
“crossdomain.xml vulnerability” 18 unique hits

Six months ago, I ran across my first extremely permissive crossdomain.xml file, but I was left with two questions:

  • How do I determine if there is really any risk to this particular web application?
  • If there is risk, how can I demonstrate this with a working exploit?


The answer to the first question can be found in the articles and papers that I linked to above. The answer to the second question, however, was not very accessible until recently.

In August 2013, Gursev Kalra released an excellent blog post and uploaded his sample ActionScript exploit code to GitHub. Thanks to Gursev, I finally had the information I needed to be able to put all the pieces together and exploit this vulnerability.

The Vulnerability

As a general rule, if the following three conditions are met, there is problem:
  1. A crossdomain.xml file is hosted at the root of the host, for example:
  2. The crossdomain.xml is overly permissive.
  3. There is either sensitive information on or there are sensitive actions that can be performed on

If #1 and #2 are met, but does not contain any sensitive information, or does not include the ability to perform any sensitive actions, there is no risk to having a wide open crossdomain.xml file. There is no point in making a victim make a request to a page for you if the information is all public and you can see everything anyway.

However, if there are sensitive actions that can be performed or information that can be stolen, and has an overly permissive crossdomain.xml file, the application at is essentially opening the door to any malicious SWF loaded from anywhere on the web. For example, a SWF loaded from is now able to override/bypass Same Origin Policy and gain access to everything that the authorized user of has access to. To say this in a different way, the overly permissive crossdomain.xml file allows Flash to do things that even JavaScript is not allowed to do, mainly accessing cross domain resources.

Note: The most permissive configuration option is the following line: <allow-access-from domain=”*”>. That is not the only overly permissive setting. Check out the reference papers listed above to find more.

Note: API sites that require a pre-shared key are an exception to the conditions listed above.  In this case, even when all three conditions are met, if requires an API key or something similar to access the content, there is no risk. The attacker has no way of knowing the pre-shared secret API key, and therefore they can not forge a request with all of the required information to exploit the permissive crossdomain.xml.

Note: In my examples, I use www as the hostname (  The security implications of the crossdomain.xml are specific to the fully qualified domain name, including hostname and/or subdomain if they are present.  For example, if the <allow-access-from domain=”*”>, but all of the sensitive transactions happen on, there is no risk.  Of course, if exists and it also has an overly permissive policy, then we are back in business.  


Update: If you don’t want to follow the step by step below, I have automated it. 
Check it out here:
Demo here:

At first I made a bash script that just automated what you see below, but after that I switched it to python and now you don’t even need to set up apache or anything like that. The python script will set everything up, help you configure your payload, and start a simple, custom, web server for you:

And now the fun part. For the demo, I’m using Kali Linux. If you want to take advantage of the vulnerability described above, you need to modify and compile a SWF and host it on a web server.  The steps below show you how to do that, from start to finish.

1) Install Adobe Flex:

2) Download Gursev’s exploit code (the .as and the .html files) from GitHub or copy/paste from his blog. In either case, you want to save the HTML into the web root (/var/www/crossdomain/xdx.html), and the AS file in a working folder outside of your web root (~/crossdomain/

If for some reason you don’t have the git client or the git command in the previous box doesn’t work, you can use wget:

3) Modify the ActionScript file to fit your needs. To make a basic GET request, Gursev’s comments are self explanatory. You just replace the victim URL and the attacker URL.  My changes are highlighted in yellow.

If you want to have the SWF make a POST request, of if you need to set a HTTP header, you can use my example below:

4) Compile the ActionScript with xmmlc:

5) Move the compiled SWF somewhere inside your web root

6) Create and save the catcher file. This php file takes the entire data portion of the incoming HTTP message and writes it to a file in /tmp. You can get a lot fancier with this, such as creating a separate file per victim, or by parsing the file within php and only writing the relevant information to disk.

7) Install PHP if it is not already installed:

8) Set your web server to support SSL.

*This step is optional, but if your flash object is communicating with a HTTPS site, and the secure=”false” attribute is not set, your flash object needs to have been loaded from a HTTPS site. 

The two lines below show you how to make a self-signed cert. For a more realistic POC, you would want to purchase a valid SSL certificate so your victim user does not get any SSL errors.

9) Start [or restart] your web server

10) Phish your victim to your site,

11) Hope the victim is currently logged in to the

12) Collect and analyze your stolen data:

Leave a Reply

Notify of