Flash ignores Content-Type header, allowing XSS?

Question

I recently read that the Flash plugin ignores the Content-Type header in certain circumstances. In particular, you can give Flash a URL, and the Flash plugin will happily fetch the content at that URL and load whatever it receives as a SWF file, with the permissions of the site that the content was loaded from — even if the response comes with a Content-Type: text/plain header (or any other Content-Type at all). The Content-Type header can indicate that this is not a SWF file, and Flash will still load this as a Flash file. The content that's loaded doesn't even have to be a valid SWF file; it just has to start with a valid SWF file, and the Flash plugin will ignore any additional cruft that follows.

The source for this claim: http://50.56.33.56/blog/?p=242

If this is true, this is not good. It means that my site is vulnerable to XSS, if there is any page where the attacker can control the start of the page. It means that my site can be vulnerable even if I carefully set the Content-Type header correctly everywhere. It means that the standard defenses against XSS when serving user-uploaded content are not sufficient.

For instance, if you want to allow the user to upload an arbitrary text file and serve it to anyone who asks, a standard approach is to make sure to set Content-Type: text/plain on the response. It's widely believed that this is sufficient to be secure. If I understand this vulnerability correctly, this practice is not secure: a malicious user can upload a malicious text file containing the contents of a SWF file, and then cause it to be executed by the Flash plugin, creating the moral equivalent of a XSS vulnerability in the site.

This has me a bit gob-smacked. Is it really true? Does Flash really have this vulnerability? Has Flash been patched to fix this? Are there any mitigating factors? Is there any clean server-side defense to prevent this kind of attack?

Answer 1

It means that the standard defenses against XSS when serving user-uploaded content are not sufficient.

The standard defence against XSS when serving user-uploaded content is to serve it from a different address (ideally different domain and IP address completely, but a subdomain stops some attacks at least). That is, you allow it to fall victim to XSS, but isolate it so that such a compromise doesn't hurt the main site.

For instance, if you want to allow the user to upload an arbitrary text file and serve it to anyone who asks, a standard approach is to make sure to set Content-Type: text/plain on the response. It's widely believed that this is sufficient to be secure

A lot of things that are completely untrue are widely believed.

Content-Type/Content-Disposition was never a sufficient defence, in the face of type sniffing (from both the browser and plugins). text/plain is the worst possible case: because it was (inadvisably) included as a default Content-Type in Apache, most browsers will completely ignote that type in favour of sniffing magic words from the start of the file.

Has Flash been patched to fix this?

No. Though there's a worse one with crossdomain.xml syntax being buried inside other filetypes and loaded through getPolicy() that has been mitigated somewhat.

Are there any mitigating factors?

The kind of interaction allowed from Flash under its own variant of the Same Origin Policy doesn't necessarily allow you full scripting into the JS origin. But yeah, it's pretty bad.

Java and Silverlight have similar problems.

Answer 2

Content-type is not intended to provide security; it is merely a suggestion to the browser as to how a web page should be interpreted in the absence of other information.

There's nothing stopping your web page (e.g. as part of a flash object) from loading page content decorated with whatever content type you like and interpreting it as something else. This can happen with a flash object, or via systems like XmlHttpRequest. (If you run an XHR query and eval the result, or blindly insert the result into the page, you'd be just as toast)

Put another way, the content type tells the browser what basic behavior to give a piece of content. If your client code, be it JavaScript, Flash, or what have you, says to do something different, then that something different is going to happen.

Answer 3

X-Content-Type-Options: nosniff might just be your friend. It instructs the browser not to guess the content-type but stay true to what the server says.