Does your Flash movie stop working because your links need the crossdomain.xml file, but you can’t place it at the root level?Â The crossdomain.xml file can be relocated to non-root locations, and that location can be defined in your Flash movie. The code is at the bottom of this article, and below is some expert advice on Flash security and cross site request forgery issues you must understand to protect your site.
When an attempt is made to load content into a SWF file at runtime, the request is subject to the Flash Player security model, which is in place to protect users and website owners. As part of this model, Flash Player by default prevents cross-domain loading of data, but allows cross-domain sending of data.
This article discusses some of the common security issues that you should consider when deciding how to use a cross-domain policy file on your server. In general, websites using cross-domain policy files increase their security exposure. This is because the cross-domain policy file used by Flash Player allows access to information by more domains than are allowed in the default configuration. As with any security mechanism, use of the cross-domain policy requires careful analysis of the proposed application architecture and threat model to understand potential risks.
Note: Using a cross-domain policy file could expose your site to various attacks. Please read this document before hosting a cross-domain policy.
Sites that use the common practice of authentication based on cookies to access private or user-specific data should be especially careful when using cross-domain policy files. Currently, the major web browsers include domain-specific cookies on most web requests. Even when cross-domain requests are made in Flash Player, browsers include the cookies of the domain that handle the request. In other words, a SWF file that is hosted on one server can make a request to any other server, and the browser automatically appends the cookies to that request.
It has become quite common for an application to include a set of public XML web services or SOAP APIs to use in mashups. The website hosting that application may also have user-specific content that is authenticated using cookies. Cross-domain policy files are often used to allow access to these public APIs. It is in those cases where special care must be taken to ensure that allowing cross-domain access to public APIs does not inadvertently expose functionality that is intended only to be used by the browser-based UI.
One approach to limiting exposure of cookies to cross-domain calls is to place XML web services or SOAP APIs that will be made accessible through a cross-domain policy file onto a separate domain or virtual host. This architecture provides the most visible and easily understood boundary between services. Flash Player can load data only from an exact-match domain, so by placing the APIs and the cross-domain file on a separate domain, you leave the authenticated area to the default policy.
Of course, using separate domains will not be possible for all sites. Any site that is considering deployment of a cross-domain policy file should also consider exposing only those virtual directories that are intended to be shared. This can be accomplished by placing cross-domain policy files into each of the virtual directories that should be exposed.
Cross-domain policy files in specific directories indicate that the policy applies only to the contents of that virtual directory and below. For many environments, a single virtual directory that includes all public methods may be the most appropriate architecture. It is important to note that any cross-domain policy files that are not on the root level of the domain must be explicitly loaded by the Flash movie.
If trust boundaries are defined by network topology (for instance, if a data source is available only on an intranet), then those trust boundaries should be reflected within any cross-domain policy.
By default, the Flash Player security model reinforces trust based on network topology because only SWFs provided by a specific domain are able to make data loading requests against that domain. But any cross-domain policy that is more permissive than the default should consider whether any topologic features should be incorporated into the cross-domain policy. Placing an overly permissive cross-domain policy file onto a server that depends entirely on topology to establish trust boundaries could add risk to the application.
For example, a website located at app.internal.foo.com might want to allow any other internal.foo.com website to connect to the site. This can be accomplished by providing a policy file that allows *.internal.foo.com. If that policy file were to be expanded to allow all domains (*), then SWFs hosted on any website on the Internet would be able to access the website, if they are accessed by a client within the internal network.
Cross-site request forgery (XSRF)
The attachment of cookies to all requests is a frequently misunderstood property of the browser that has led to a category of web application vulnerabilities known as cross-site request forgery (XSRF). An XSRF is not unique to Flash-based applications or the cross-domain policy file, but some solutions to mitigating XSRF may be affected by the policy file.
An XSRF vulnerability can occur any time a web application has sensitive functionality that can be exercised in a single atomic request. A cross-domain request takes advantage of the cookies included with the request to initiate requests that are authenticated but may be malicious.
XSRF has affected web applications for as long as they have used cookies to implement authentication. Recently, XSRF vulnerabilities have received much attention within the security community because they have been discovered in some widely used web applications.
Common techniques for reducing exposure to XSRF include limiting the duration of cookies, checking the referrer field, and adding non-cookie based authentication information such as a time-based hash message authentication code (HMAC) or state machine in a hidden field. Because cross-domain policy files allow inspection of the data loaded from another site, they can limit the effectiveness of some in-band non-cookie authentication mechanisms such as hidden fields in document state management. Carefully review any application for XSRF and determine whether the countermeasures will be sufficient before making changes to a site’s cross-domain policy.
This article recommends a number of specific security issues that should be reviewed prior to deployment of a cross-domain policy file:
- Carefully evaluate which sites will be allowed to make cross-domain calls. Consider network topology and any authentication mechanisms that will be affected by the configuration or implementation of the cross-domain policy.
- Limit the scope of the cross-domain policy to only the desired functionality by creating subdomains or virtual directories containing shared functionality.
- Review any XSRF prevention mechanisms to see if they may be affected by allowing cross-domain data loading.
Where to go from here
For more information on the cross-domain policy file and Flash Player security in general, please see the following resources:
- Adobe Flash Player 9 security white paper (PDF, 588K)
- Adobe Security Center
About the author
Lucas Adamski is the platform security strategist at Adobe. With over 10 years of experience with software development, security, and architecture for companies such as @stake, Breakwater Security, and Inktomi Corporation, Lucas is responsible for the trustworthiness of platform products, including Flash Player, Flex, and AIR
About custom policy file locations
Flash Player 7 (188.8.131.52) supports a new method called
System.security.loadPolicyFile. This method lets you specify a custom location on a server where a cross domain policy file can be found, so it does not need to be in the root directory. Flash Player 7 (184.108.40.206) only searched for policy files in the root location of a server, but it can be inconvenient for a site administrator to place this file in the root directory. For more information on the
loadPolicyFile method and XMLSocket connections, see About XMLSocket policy files and
System.security.loadPolicyFile in Flash ActionScript Language Reference.
If you use the
loadPolicyFile method, a site administrator can place the policy file in any directory, as long as the SWF files that need to use the policy file call
loadPolicyFile to tell Flash Player where the policy file is located. However, policy files not placed in the root directory have a limited scope. The policy file only allows access to locations at or below its own level in the server’s hierarchy.
loadPolicyFile method is available only in Flash Player 7 (220.127.116.11) or greater. Authors of SWF files using the
loadPolicyFile method must do one of the following:
- Require Flash Player 7 (18.104.22.168) or later.
- Arrange for the site where the data is coming from to have a policy file in the default location (the root directory) as well as in the non-default location. Earlier versions of Flash Player will use the default location.
Otherwise, authors must create SWF files so a failure of a cross-domain loading operation is implemented.
Caution: If your SWF file relies on loadPolicyFile, visitors with Flash Player 6 or earlier or Flash Player 7 (22.214.171.124) or later will not have problems. However, visitors with Flash Player 7 (126.96.36.199) will not have support for loadPolicyFile.
If you want to use a policy file in a custom location on the server, you must call
System.security.loadPolicyFile before you make any requests that depend on the policy file, such as the following:
System.security.loadPolicyFile ("http://www.foo.com/folder1/folder2/crossdomain.xml"); var my_xml:XML = new XML(); my_xml.load("http://www.foo.com/folder1/folder2/myData.xml");
You can load several policy files with overlapping scopes using
loadPolicyFile. For all requests, Flash Player tries to consult all the files whose scope includes the location of the request. If one policy file fails to grant cross domain access, another file is not prevented from granting access to data. If all access attempts fail, Flash Player looks in the default location of the crossdomain.xml file (in the in the root directory). The request fails if no policy file is found in the default location.