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 www.foo.com cannot place requests to www.bar.com. 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.
http://www.foo.com/crossdomain.xml
< ?xml version="1.0"?>
< !DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<>
< domain="www.bar.com">
< domain="*.foo.com">
< /cross-domain-policy>
< domain="www.bar.com">
Says Flash Movies on www.bar.com can make asyncronous HTTP Requests to www.foo.com
< domain="*.foo.com">
Says Flash Movies anywhere on foo.com can make asyncronous HTTP Requests to www.foo.com
< domain="*">
Says Flash Movies from anywhere can make asyncronous HTTP Requests to www.foo.com. 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 www.hacker.com to load in a malicious Flash Movie. That movie would have full domain access to www.foo.com 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.
4 comments:
Hi Jeremiah,
I think a Flash movie hosted on www.foo.com can in fact place arbitrary requests to www.bar.com. If this would not be possibe this article would not make much sense.
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.
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.
Hi
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?
-Nate
Post a Comment