Main Content

Heya - HollyGraceful here, I make all of this content in my spare time, like it? Please support me :)
You can donate via Bitcoin or Patreon!

Cross-domain Flash and Silverlight (crossdomain.xml)

Now I’ve posted previously about cross-domain communication with things like HTML5 CORS and HTML5 postMessages, I’ve also written about the browsers built in protections through Same-Origin Policy. However, recently I saw a discussion about Cross-domain Flash and Silverlight and how those are different, how specifically the exploitation works and what it offers an attacker.

Before I get into that: A very short recap of Same-origin Policy (SOP) is that it is a built-in protection of web browsers that ensures that websites or different origins cannot interact with each other. Where a “different origin” is defined as an application with a different protocol, port, or domain. “Cannot interact” is defined as an application can generate a request to another origin, which will be processed, but the requesting origin cannot read the response. This leads to attacks such as Cross-site Request Forgery which I’ve written about here.

Cross-domain policies are a way of reducing, or even crippling, the browsers default protections. This is often a requirement for modern companies who own several disparate applications but would like them to be able to interact (such as to allow for single-signon). Think of Companies like Google who also owns YouTube, or Microsoft which owns Outlook. These companies may want separate domains for their applications but still require information to be shared.

To enable the sharing of information between domains with Flash or Silverlight, developers can make use of a crossdomain.xml file saved at the root of their application. (Oh and here’s the official documentation for flash crossdomain.xml and silverlight crossdomain.xml to save you searching). This file informs the browser that it should allow additional origins to interact with the target application. These interactions include credentials in the form of cookies which are automatically included by the browser.

This means that if your application has a lax cross-domain configuration and a user navigates to my application, or the user can be coerced into visiting my site – then my application can impersonate that user and establish two-way communications with your application as that user. Effectively I can host a Flash or Silverlight application on my page and it can send requests to your application as the user and process the responses, effectively bypassing authentication, any protections such as cross-site request forgery prevention tokens and allow for the theft of confidential data and potentially account takeover. My site doesn’t have to interact with an Flash/Silverlight App on your site, it can interact with your application using HTTP.

So cross-domain policies are critical to the overall security of your application, they should be as strict as possible and be developed as a whitelist of allowed applications. I recommend that you entirely avoid the use of wildcards and that your review the policy regularly to ensure that there are no more applications listed than necessary. Additionally, that if you decommission an application that your ensure it is removed from your cross-domain policy.