Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

In his book Michal Zalewski says:

To protect your users, include a top-level crossdomain.xml file with the permitted-cross-domain-policies parameter set to master-only or by-content-type, even if you do not use Flash anywhere on your site. Doing so will prevent unrelated attacker-controlled content from being misinterpreted as a secondary crossdomain.xml file, effectively undermining the assurances of the same-origin policy in Flash-enabled browsers.

Currently site has the following policy for user-uploaded files:

  • All downloads have Content-Disposition: attachment
  • User-uploaded files' download links are placed on separate domain from main site
  • X-Content-Type-Options:nosniff

In case if there is no crossdomain.xml how can attacker place crossdomain.xml so that it will be interpreted as valid crossdomain.xml? What if crossdomain.xml is present? Do other vulnerabilities related to crossdomain.xml exist?

share|improve this question
add comment

2 Answers

up vote 2 down vote accepted

I don't know. I'm not Michael Zalewski, and I can only speculate about the basis behind this advice. Did he say anything more in the book?

The crossdomain.xml file contains policy that Flash uses to determine how other sites may interact with this site. If it contains a permissive policy, then bad things can happen. Therefore, you don't want users to be able to upload a policy that sets a permissive policy for your site.

There are three risks that I'm aware of:

  1. These days, by default, Flash will look for the crossdomain.xml file at the root of your site: http://www.example.com/crossdomain.xml. If a user has the ability to upload files into the root of your site and choose its filename, the user could choose the filename crossdomain.xml and choose its contents to specify a permissive security policy. That'd be bad.

  2. I believe that once upon a time, Flash applets could specify where to look for the crossdomain.xml policy file; in particular, Flash would gladly look somewhere other than the root of your site. Suppose you allow users to upload files of their choosing, with their own choice of filename, into the /uploads directory. A malicious user could upload to http://www.example.com/uploads/crossdomain.xml. Then, the malicious user could host an evil Flash applet on their own site and have it tell the Flash platform that www.example.com's policy file can be found at http://www.example.com/uploads/crossdomain.xml. Flash would happily comply, leading to unhappy consequences.

    I believe that modern versions of Flash player no longer suffer from this vulnerability. They will always look first at the root directory, to check for a crossdomain.xml, and will only look for crossdomain.xml files elsewhere if the one at the root allows it.

  3. Once upon a time, older versions of Flash player had security flaws that would allow an attacker to fool Flash player into looking somewhere other than the root directory for the crossdomain.xml file. Then we're in the same situation as the previous risk. I believe this vulnerability has been fixed long ago.

I don't know whether the latter two risks are relevant any more. I think they've been fixed long ago. However, I suppose it is possible some of your users might be using old versions of Flash player that still have this problem.

Given what you said about hosting all user content on a separate domain, as far as I know, your site should be safe, even if you don't take any further actions. However, maybe Michael Zalewski knows something I don't know. (OK, I'm sure he knows a lot that I don't know; I mean, maybe he knows some fourth risk/attack that I'm not aware of.)

share|improve this answer
add comment

Here is an answer from Michal Zalewski that I received from email:

The concern is that is that Flash can be pointed to any URL to interpret it as crossdomain.xml; so for example, if you allow users to upload images, download CSV reports for their data, or host any other sort of attachments or generated text files, you are at risk. Requiring the MIME type to match precisely is a simple countermeasure.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.