Original source -- http://my.safaribooksonline.com/book/networking/security/9780596806309/inside-out-attacks-the-attacker-is-the-insider/content_ownership
2.4.1. Abusing Flash’s crossdomain.xml
The same origin policy can often be deemed too restrictive, causing application developers to clamor for the ability for two different domains to work interactively with each other. One of the first popular browser plug-ins to support such cross-domain interaction was Adobe’s Flash. Adobe understood the dangers of allowing arbitrary cross-domain access and implemented a security measure to determine whether Flash would allow for cross-domain interaction. This security measure is implemented via the cross-domain policy file.
Flash’s cross-domain policy file defines the “rules” for cross-domain interaction. The cross-domain policy file is simply an XML file named crossdomain.xml. Here is an example of a crossdomain.xml file:
<?xml version="1.0" encoding="UTF-8" ?>
<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="*" /> </cross-domain-policy>
This crossdomain.xml policy file must be hosted on the server that wishes to allow for cross-domain interaction. Before allowing cross-domain interaction, Flash will check for the presence of a cross-domain policy file on the target domain. If no policy file exists, Flash defaults to the restrictive same origin policy and disallows cross-domain interaction. If a crossdomain.xml file exists on the target domain, Flash reads the “rules” contained within the policy file and allows cross-domain interaction based on the established rules. Once again, the entire premise is based on the fact that the cross-domain policy file must be served from the domain that wishes to allow the cross-domain interaction. By default, Flash will check for the presence of a cross-domain policy file named crossdomain.xml in the web application’s web root (http://www.example.com/crossdomain.xml).
Beginning with Flash 7, you can make Flash check for crossdomain.xml in arbitrary locations (not just the root of the web root) when the Flash component invokes loadPolicyFile() with a URL as the parameter (containing the location of crossdomain.xml on the target server).
NOTE
You can find more information on System.Security.loadPolicyFile() at the following website:
http://livedocs.adobe.com/flash/mx2004/main_7_2/wwhelp/wwhimpl/common/html/wwhelp.htm?context=Flash_MX_2004&file=00001098.html
The concept of Flash’s cross-domain policy is based on a few simple premises. A simplified version of the logic is as follows:
The cross-domain policy file must be located in a web-accessible path of the web server to allow for cross-domain access from Flash to that server.
The only way someone can put an arbitrary file into a web-accessible path of the web server is if he has administrative access to the web server.
Therefore, if the web server has a cross-domain policy file in a web-accessible path on the web server, an administrator must have placed it there.
This logic is inherently flawed because many web applications allow users to upload content to the web server. If the application subsequently serves that content under its domain name, that web application has unknowingly put itself at risk because of Flash’s cross-domain abilities. If an attacker is able to upload a crossdomain.xml policy file, the attacker can use an evil Flash applet on her web server to attack the vulnerable application. This evil Flash applet will be able to make cross-domain requests to the vulnerable web application and those requests will be made with the session cookies of any unfortunate users who happen to stumble upon the attacker’s website. To make matters worse, the cross-domain policy file need not have the .xml extension. Flash’s security criteria will honor any file extension.
NOTE
Adobe Flash 9.0.115.0 allows for the specification of “meta-policies.” These policies define which policy files on the server should be honored. You can find more information on meta-policies at http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security_03.html.
