Monday, October 09, 2006

crossdomain.xml statistics

I've been reading Chris Shiflett's blog on Dangers of Cross-Domain Ajax with Flash and crossdomain.xml insecurities. This area could potentially make Cross-Site Scripting (CSRF) and Cross-Site Request Forgeries (CSRF) issues a lot worse. A lot depends on the circumstances, but its time to learn a little bit more about this. For background...

As in JavaScript/AJAX, Flash Players are restricted from placing asyncronous HTTP requests to off-domain url's. (same-origin policy) For example, a Flash movie hosted on cannot place requests to The policy prevents malicious Flash movies from compromising sensitive users data on other websites, but also hinders development of cool new website mash-ups (without relying on a server-side proxy). This is where crossdomain.xml comes in. crossdomain.xml is an XML policy file that gives Flash Players specific permission to access data from a given domain.
< ?xml version="1.0"?>
< !DOCTYPE cross-domain-policy SYSTEM "">

< domain="">

< domain="*">

< /cross-domain-policy>

< domain="">
Says Flash Movies on can make asyncronous HTTP Requests to

< domain="*">
Says Flash Movies anywhere on can make asyncronous HTTP Requests to

< domain="*">
Says Flash Movies from anywhere can make asyncronous HTTP Requests to This looks particularly dangerous.

Check this Flash Player TechNote snippet says about it:
"This practice is suitable for public servers, but should not be used for sites located behind a firewall because it could permit access to protected areas. It should not be used for sites that require authentication in the form of passwords or cookies."

Fair enough, but who reads the docs anyway. Let's say you XSS somebody on to load in a malicious Flash Movie. That movie would have full domain access to provided the wildcard config was in place. One of my first questions was ok while interesting, this is obscure technology, is unlikely to be widely deployed. As such, of nominal risk to the enterprise. To make sure I ran some tests on the websites of the Fortune 500 and the Alexa 100 (US). Here are the stats:

I was surprised at the results. A total of about 8% of the Fortune 500 have crossdomain.xml policy files and 2% of those were wildcarded for any-domain. The Alexa 100 was even more pronounced. About 36% have crossdomain.xml, 6% of which are wildcarded for any-domain. This says to me the risk is there and will likely grow.


Anonymous said...

Hi Jeremiah,

I think a Flash movie hosted on can in fact place arbitrary requests to If this would not be possibe this article would not make much sense.

Anonymous said...

Anonymous, you're right, and we should probably be clearer when discussing these topics.

Cross-domain requests have been possible for a long time using both GET and POST. Using Flash, cross-domain requests can be sent using both GET and POST, and you can additionally manipulate request headers such as Referer.

These techniques open the door for many attacks, but what Jeremiah is discussing in this post is something slightly different. With an open crossdomain.xml file, an attacker can use Flash to both send HTTP requests and receive the HTTP responses. In other words, any sensitive data in the response (such as a token being used as an anti-CSRF safeguard) is available to the attacker and can be analyzed and used in additional, more damaging attacks.

Hope that makes things a bit clearer. As I said, you're right, but these new discoveries are still important.

Jeremiah, thanks for helping to raise awareness.

Nathaniel C. Gallagher said...

Is there any way to change the crossdomain.xml file on your blogspot page?
I am having this issue for mine and I noticed that the crossdomain.xml file for this blog is blank.

Nathaniel C. Gallagher said...

I noticed that the crossdomain.xml file for this blog doesn't allow any domains.
Do you know of anyway to change the crossdomain.xml file on your blogspot account/site?