We are blacklisting a number of MIME types on our proxy server so users can't download certain file types, for example, executables.

Could it be possible that somehow, a malicious server can trick a user (maybe through script exploits or drive-by) to browse and download a malicious executable, bypassing the blacklist? Let's assume the proxy server only allows HTTP traffic.


On older browsers, the answer is yes, this kind of attack is possible, due to some browsers' support for MIME content-type sniffing. You can Google for content-sniffing attacks and you'll find a lot more details.

To defend against it, set the header X-Content-Type-Options: nosniff (only supported on IE8 and IE9, I think), and make sure to serve a valid content-type in the Content-Type: header. Those will disable content-type sniffing on many browsers (on IE8, IE9, and non-IE browsers, at least).

See also Using file extension and MIME type (as output by file -i -b) combination to determine unsafe files?, Does X-Content-Type-Options really prevent content sniffing attacks?, What are the security risks of letting the users upload content to my site?, How can I be protected from pictures vulnerabilities?, Is it safe to serve any user uploaded file under only white-listed MIME content types?, MIME sniffing protection, Why should I restrict the content type of files be uploaded to my site?.

I also recommend that you serve user-uploaded content from a separate domain, to sandbox the user content and ensure it cannot tamper with your content. For instance, you might host your content on www.example.com and host user-provided content on uploads.example.com.

Update: I just learned that setting the Content-Type and X-Content-Type-Options headers are not enough for security. Apparently, Flash ignores the Content-Type header, which could allow loading a malicious SWF, which can then do everything you'd do with a XSS. (Sigh, stupid Flash.) Unfortunately, no amount of headers can stop this attack. Consequently, it appears that the only safe solution is to host the user-uploaded content on a separate domain.

  • Thanks for the comment D.W.. However in my case I have no control over the web server; I'm on the client side downloading files. But I have a browsing proxy that can be configured to blacklist certain MIME types. While content-sniffing remains a potential attack vector, I was wondering if it's possible for a browser (through malicious servers or client-side scripts) to download executables that somehow get through the proxy blacklisting.
    – lithium
    May 22 '12 at 1:05
  • Interesting, most MIME questions listed are also from those new to this site with low rep. Perhaps the search functionality is confusing users MIME with S/MIME results May 22 '12 at 4:35
  • @lithium, I believe the answer is yes, it is possible for a malicious executable to get past your proxy, despite the blacklist of MIME types. An attacker can create malicious content that is served as (say) Content-Type: text/plain but that some IE browsers will treat as some sort of malicious executable (or other dangerous MIME type). The attack exploits IE's MIME content-type sniffing algorithms. See the links in my answer, and especially the research paper by Barth et al. for a definitive treatment.
    – D.W.
    May 22 '12 at 5:37
  • @D.W. Thanks, actually it was first through the searches I learnt about the content sniffing exploit. But I think what I was getting at was a malicious script could well get a browser to codeGETcode an executable from a server that, say, specifies the MIME type as codetext/plaincode, save it somewhere, and run the executable from the saved location, and there's nothing the proxy can do about it.
    – lithium
    May 23 '12 at 6:43
  • @lithium, yes, good point. As far as I know, that is a realistic risk as well.
    – D.W.
    May 23 '12 at 23:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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