2

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.

lithium
  • 23
  • 2

1 Answers1

2

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.

Community
  • 1
D.W.
  • 98,420
  • 30
  • 267
  • 572
  • 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 01: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 – makerofthings7 May 22 '12 at 04: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 05: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 `code`GET`code` an executable from a server that, say, specifies the MIME type as `code`text/plain`code`, 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 06: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