Peleus here. There has been a recent focus on cross-domain policy deployments in the media, so I thought this would be a good time to remind people of some best practices. Cross-domain security was a focus of my recent presentation at the Microsoft BlueHat conference. I have also covered this topic within my Creating More Secure SWF Web Applications article. With more plugin platforms adopting the format and similar controls being added to HTML5, it is becoming increasingly important to ensure the correct deployment of a cross-domain architecture. Here are five best practices that should be followed to ensure a secure deployment.
1. Avoid full wildcard permissions (domain="*", headers="*", to-ports="*"). There are only a small number of legitimate use cases for full wildcard (*) permissions. If granting full permission is absolutely necessary, then the best practice is to create a sub-domain on your site whose explicit purpose is to serve cross-domain data. Another option is to leverage Flash Player's support of per-directory cross-domain permissions and place the data and the full wildcard cross-domain policy within a sub-directory of the site dedicated for that purpose. Full wildcards on internal networks can also be dangerous since they can result in external content being granted access to internal resources. A full wildcard should also never applied to the headers attribute of the allow-http-request-headers-from element or the to-ports attribute of the allow-access-from element in production. Once a wildcard permission has been deployed, it can be very challenging to restrict permissions at a later date because there is no easy way to identify what content depends on that permission.
2. Don't use sub-domain wildcards (*.example.org) with domains that allow user-uploaded content. This issue has grown as an increasing number of sites on the web support hosting user generated content. Quoting Microsoft's 10 Immutable Laws of Security, "Law #4: If you allow a bad guy to upload programs to your website, it's not your website any more." Therefore, if you are granting cross-domain permission to *.example.org and upload.example.org hosts end-user content, then you are not trusting just example.org. You are also trusting all the users who are permitted to upload content to upload.example.org. An attacker can upload a malicious SWF to upload.example.org, use the *.example.org permission to retrieve sensitive data from your site and then pass that data back to the attacker's web site.
3. Avoid cross-domain permissions on sites that require authentication. Any data that requires authentication for access probably should not be available to third-party domains. Flash Player does not provide access to the header of an HTTP response. Therefore developers may assume that SWF content cannot gain access to the session information stored within the cookie headers. However, some architectures will add the session information as a parameter onto the end of a URL contained within the response body where an attacker can gain access to it. Once an attacker has access to the session information of the victim, they can impersonate that user.
4. Cross-domain policies require periodic maintenance. Your web site will grow and change over time and you will need to reevaluate the cross-domain permissions with respect those changes. If you are granting permissions to domains outside of your control, then keep in contact with that party to ensure that the permissions are still necessary and that they are still used within the same context. You can limit your risk by periodically removing excess permissions.
5. Cross-domain permissions are not the only method for sharing data between domains. Rather than using the client to bridge two domains, consider using server-side code to make the cross-domain request via a server-to-server channel. Server-side code can enforce stricter controls on the request and act as a proxy between the client and the second domain. This has the trade-off of increasing traffic to the server but may allow for a more controlled channel. Be sure to consider all of your options before determining the best solution.
Cross-domain policies are a part of the code that makes up your web application. Like any other code, they require periodic maintenance and review to ensure security. Cross-domain policies should follow the same principle of least privilege that you apply to code. Only the minimum permissions required for the architecture should be enabled. The best architectures are simple and straightforward. Creating a sub-domain whose explicit purpose is to host cross-domain content can prevent unintentional disclosure. Overall, approach cross-domain policies as you would any other code. Following these best practices can help you secure your cross-domain deployment.
For further information and best practice guidance, please see:
-
Cross-domain policy file specification : Describes the structure of the cross-domain policy file.
-
Cross-domain policy file usage recommendations for Flash Player: 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.
-
Flash Player 10 Security: This white paper provides a broad overview of the Flash Player security model including cross-domain policies.
-
Understanding the Flash Player Security Model: A video of Deneb Meketa's presentation from MAX 2008 which discusses cross-domain security.
-
Creating more secure SWF web applications : A Developer Center article on how to secure SWF content including cross-domain policies.
-
ActionScript Developer's Guide: This is the cross-domain policy section from the Flash CS4 Professional documentation.
