A survey of insecure Flash crossdomain policies – Alexa Top 10,000 case study

EDIT: October, 9th 2015 – added Appendix section.

Just like many other information security consultants, most of my billable time is spent performing web application penetration testing. Also just like every other professional pentester out there, I rely a lot on Burp Suite and its amazing scanner.

More often than not, Burp Scanner comes up with a finding that, under certain conditions, can have a rather high impact but is not commonly exploited: insecure crossdomain.xml file.

In a recent blog post, Matthew “mandatory” Bryant exploited this vulnerability against the popular music service rdio. This inspired me to conduct a survey against Alexa Top 10,000 most visited sites on the web (October 2015) in order to verify how widespread crossdomain vulnerability actually is, as well as hopefully raise awareness about the issue. It is worth mentioning there is some prior art on this exact same topic published in an academic paper from 2011 and a blog post by Zach Bloomquist, but I was not aware of any of them until I started to write the support code for this survey.

The rest of this blog post briefly discusses what crossdomain policy is and how it can affect the security of a website. It also describes all steps necessary to conduct the survey, including the relevant technical details and code, and presents its results.

Hello, my name is crossdomain policy

Same Origin Policy is a fundamental part in web browser’s security model. This security boundary restricts how a resource (e.g., script) loaded from a given origin interferes with documents of another origin. More information about same origin policy can be found here.

The way Flash adheres to a model similar to SOP is through crossdomain policy. A server providing content (e.g., target.com) to a Flash-based application hosted in another server (e.g., example.com) will make its policy available via a XML file crossdomain.xml. This file contains details regarding the policy — i.e., what it permits and restricts, which domains can issue cross-origin requests, etc.

Before performing crossdomain requests against a particular domain the Flash plugin does the following:

  • Issues a pre-flight request to fetch http://www.example.com/crossdomain.xml
  • Parses the XML file to see whether the domain where it is running from (origin) is authorized by the target server to issue crossdomain requests
  • If authorized to do so, sends the request and gains the ability to read the response

It is important to stress that requests performed via Flash are “cookie-carrying”; in other words, they have the ability to use the browser’s cookie jar and issue requests with the appropriate cookies, if necessary.

Taking twitter.com’s crossdomain policy as an example, usually these files have the following format:

<cross-domain-policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.adobe.com/xml/schemas/PolicyFile.xsd">
<allow-access-from domain="twitter.com"/>
<allow-access-from domain="api.twitter.com"/>
<allow-access-from domain="search.twitter.com"/>
<allow-access-from domain="static.twitter.com"/>
<site-control permitted-cross-domain-policies="master-only"/>
<allow-http-request-headers-from domain="*.twitter.com" headers="*" secure="true"/>

The tag ‘allow-access-from’ through the value ‘domain’ specifies which origins can issue crossdomain requests. It is possible to use a wildcard character to denote all subdomains of a given URL are allowed to crossdomain, or even to allow every host on the Internet to perform such requests.

For example, the following policy allows any subdomain of twitter.com to issue cross-domain requests:

<allow-access-from domain="*.twitter.com"/>

Security ramifications of a relaxed crossdomain policy

A very liberal crossdomain policy can have a serious adverse impact to the security of a website. Through Flash it is possible not only to send cookie’d cross-origin requests, but more importantly the ability to read the response.
This essentially overrides all security benefits brought by Same Origin Policy. Say, for example, a site embeds an anti-CSRF token — now it is possible for an attacker to, through his malicious Flash applet, send a request to fetch the token and perform actions that otherwise would be non-CSRFable, or read sensitive information like authorization keys (in the case of rdio exploit).

For more detail refer to Seth Art’s very informative post on exploitation of crossdomain vulnerabilities.

Getting practical

The experiment was only conducted with Adobe Flash crossdomain.xml. Microsoft Silverlight has a similar .xml file for crossdomain requests but it was out of scope for this survey, mostly because Silverlight’s popularity is minimal compared to Flash.

The first step was to download Alexa Top 10,000 from here. Extracted the file and then executed the following one-liner to get the first 10,000 records:

$ head -n 10000 top-1m.csv | cut -d "," -f 2 > top10000.txt

The algorithm used to classify the strenght of the policy is a very simple set of conditionals.

  • If a wildcard is found in the domain tag, immediately mark the policy as insecure
  • If the domain in the XML has a close match the domain (e.g., static.twitter.com for Twitter’s crossdomain.xml), mark it as secure as, in theory, it is controlled by the same organization and expected to adhere to its security policies and practices.
  • If the domain in the XML is a third party URL, it is considered as moderately secure as the third party URL may be out of control of the main domain.

The code can be found at https://github.com/juliocesarfort/crossdomainer


Out of 10,000 websites surveyed, 3110 (31.10%) contained crossdomain.xml file on its root directory. In this total, 968 sites have the weakest form of crossdomain policy. This accounts for 31.125% of the policies analyzed. This pretty high percentage suggests that the risks involving crossdomain policies may not be well understood by many web developers.
Out of the 10,000 most popular websites of the Internet, 9.68% expose their users to the risk of crossdomain-related vulnerabilities.

These numbers were obtained by opening the resulting SQLite database and typing the following commands:

sqlite> select count(*) from crossdomain;
sqlite> select count(*) from crossdomain where rate='Insecure';

I personally could not recognize most of these sites, assuming many of them are popular in Asian and European countries I am not familiar with. However, some big names were spotted during this research. Although I do not mean to name and shame any companies and organizations, I think it is important to mention at least a few of them hoping they will get their policy right and improve their overall security posture:

– fox.com
– newsweek.com
– brazzersnetwork.com
– collegehumor.com
– sputniknews.com
gandi.net (fixed in less than 24 hours after this post went online)
– vh1.com
– nhs.uk
– auspost.com.au
– gigaom.com
– krakow.pl
– afip.gob.ar
– netshoes.com.br


Sadly, roughly 10% Internet’s most visited websites have weak crossdomain policies and may be subjected to abuse. Out of more than 3100 sites that use Flash and have an active crossdomain policy file, an approximate 30% of them are vulnerable. This suggests a lack of understanding of the threats associated to attacks involving crossdomain requests and may expose sites used by a large number of users to unecessary risk.


October 9th 2015: Christophe, a security engineer at Gandi.net, contacted me via e-mail to inform they have already fixed the issue on 2015-10-05 09:06:59 UTC, less than 24 hours since the post was made public. Kudos for the prompt response to the issue!

A survey of insecure Flash crossdomain policies – Alexa Top 10,000 case study

One thought on “A survey of insecure Flash crossdomain policies – Alexa Top 10,000 case study

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s