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.

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 (apologies that this is a non-clickable link; StackExchange won't let me include it as a clickable link)

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?

share|improve this question

3 Answers 3

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.

share|improve this answer

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.

share|improve this answer
    
"There's nothing stopping your web page from loading page content decorated with whatever content type you like and interpreting it as something else." - I think you've missed the point. Modern browsers do respect the Content-Type header. If the response has Content-Type: image/gif, browsers won't treat it as HTML and run Javascript found in it with all the privileges of the origin from which it was loaded. (Old versions of MSIE violated this, but that's fixed in modern IE's.) Content-Type: is a critical security feature; sadly Flash doesn't respect the same rules that browsers do. –  D.W. Sep 25 '13 at 17:28
    
(cont.) eval and XHR are not analogous, because they don't involve the browser executing the content with the privileges of the origin that the content was loaded from. If a page evals some XHR'ed content, that's not the browser doing it, that's the page making an explicit trust decision. That's different from what's going on with Flash. –  D.W. Sep 25 '13 at 17:31
    
@D.W.: "Giving flash a path" to execute is the same thing as eval -- it is something the web page asked the browser to go fetch and said "this is a SWF, please interpret it that way for me". –  Billy ONeal Sep 25 '13 at 20:22
    
It's not the same thing. When evil.com can tell Flash to go fetch a resource from good.com/foo.csv and have Flash treat the response as a SWF file and execute it with the privileges of good.com, that's a very bad thing. eval() is not comparable; evil.com can use eval() to ask the browser to fetch a resource from good.com/foo.csv and then ask the browser to treat that as Javascript and execute it, but the browser will give it the permissions of evil.com. Do you see the difference? The difference is huge! –  D.W. Sep 25 '13 at 21:07

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.

share|improve this answer
    
Do you have any evidence that Flash pays any attention to X-Content-Type-Options: nosniff? I've never seen any indication of that. As far as I know, that header is supported only by (some) browsers, but not by the Flash plugin. –  D.W. Sep 25 '13 at 21:15
    
Nope, hence the use of the word "might". –  Erlend Sep 26 '13 at 19:55
    
Seems to me flash will only execute given the correct content-type these days (the frame with "Not Found" ran the flash) research.insecurelabs.org/flash –  Erlend Sep 26 '13 at 20:14

Your Answer

 
discard

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.