However it seems Adobe (or former Macromedia) was aware of the danger that arises from supporting cross domain requests, because the Flash player will only allow cross domain requests if a policy file is available on the target domain that allows access from other domains. By default this file is located in the document root directory and is called crossdomain.xml.
During the last weeks it was discovered that a lot of administrators (even of big sites) did not read the security warnings in the documentation. They placed crossdomain.xml policy files like this
<cross-domain-policy> <allow-access-from domain="*"/> </cross-domain-policy>
into the document root of their main domains, which allows cross domain access from everywhere, although the documentation clearly states that this might be dangerous and therefore should not be done.
Quote: “Note: 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.”
While even a lot of big sites are vulnerable to cross domain attacks because their admins misconfigured their servers, crossdomain.xml problems are only a question of the right configuration.
We however discovered a more serious design flaw in Flash’s opt-in policy system that can be exploited to perform cross domain attacks against sites not having opted-in.
In some situations it is not an option to have a crossdomain.xml file in the document root directory of the webserver. For such cases Flash allows to load alternate cross domain policy files. These files can be placed into arbitrary directories on the webserver and will allow cross domain HTTP request only to the directory in question and all it’s subdirectories.
While this might sound like a nifty idea to allow even finer graded cross domain policies it is ultimatively stupid because on the one hand it adds a new exploit vector to different classes of web application vulnerabilities and on the other hand it creates a whole new class of vulnerabilities in otherwise secure web applications.
To understand the whole problem and the new danger that arises from this Flash feature it is necessary to closely inspect the following facts
The policy file location can be any arbitrary URL. The policy will be valid for the path within the URL and all it’s subdirectories. The policy file location is even allowed to perform an HTTP redirect to another arbitrary location. However the player will ignore a policy on a different domain. Luckily the HTTP redirect support in the plugin seems to be broken in all tested browsers except Internet Explorer. Policies are valid for the original URL path before the redirect.
Now imagine the following example: A blog that describes (the danger of a default) crossdomain.xml. It comes with a link to download a “*” cross domain policy file. In flash it is now possible to load an arbitrary policy location:
For this demonstration it is assumed that http://dom.ext/exit.php is a little tool that redirects the user’s browser to the exit URL. (Such redirects are common. Yahoo servers for example seem to support redirects all over the site by the usage of a special URL format)
Unfortunately the Flash player will follow such an in-domain redirect to download the policy file. This means one can now do cross domain HTTP requests against the path of the policy file and all it’s subdirectories. In the example above this means the whole domain.
In some browsers like Firefox Flash seems to have a problem with the implementation of redirection support. In our tests the Flash plugin simply hanged and did not retrieve the secondary location. For these browsers it is still possible to attack web applications. Especially against those using a dispatch request model.
This URL could for example try to exploit the avatar upload feature of a bulletin board.
Policies are defined in an XML format. However the policy files do not seem to get parsed by an XML parser, because they are not required to be strict/wellformed XML files. The only restrictions that seem to apply are that ASCIIZ chars placed before the policy tags are not allowed and that bytes before the policy tags may not contain unclosed tags. These lax restrictions allow embedding valid policies in other filetypes. It is trivially possible to construct for example a GIF image with an embedded policy. Within the appendix an example for the start of such a GIF image is provided.
Looking at the facts this means Flash can be used to attack (a part of) a web application if it possible for an attacker to embedd a valid policy into the response of the application.
Potentially vulnerable web applications are
- Applications that use a blacklist approach to only disallow dangerous HTML tags in text/html output
- Applications that do not filter HTML tags because response is not text/html
- Applications that allow fileupload/retrieval (e.g. avatars in bulletin boards)
- Applications that contain PHP include vulnerabilities
- Applications that contain file retrieval vulnerabilities
We strongly believe that by introducing the possibility to specify alternate policy files within Flash, Adobe (former Macromedia) undermined their own opt-in policy model. It might be possible to fix several of the described weaknesses by adding additional protections like enforcing wellformed XML files, disallowing HTTP redirects, disallowing URL parameters, enforcing specific names, but there is still the possibility that this feature allows an attack against a webserver that did not want to opt-in.
So the best solution would be: Remove the possibility to have alternative policy file locations.
00000000 47 49 46 38 39 61 01 01-01 01 e7 e9 20 3c 63 72 GIF89a.......<cr 00000010 6f 73 73 2d 64 6f 6d 61-69 6e 2d 70 6f 6c 69 63 oss-domain-polic 00000020 79 3e 0a 20 20 3c 61 6c-6c 6f 77 2d 61 63 63 65 y>...<allow-acce 00000030 73 73 2d 66 72 6f 6d 20-64 6f 6d 61 69 6e 3d 22 ss-from domain=" 00000040 2a 22 2f 3e 20 0a 20 20-3c 2f 63 72 6f 73 73 2d *"/>....</cross- 00000050 64 6f 6d 61 69 6e 2d 70-6f 6c 69 63 79 3e 47 49 domain-policy>..
19. October 2006 - Stefan Esser