20

In Tangled Web Michal Zalewski says:

Refrain from using Content-Type: application/octet-stream and use application/binary instead, especially for unknown document types. Refrain from returning Content-Type: text/plain.

For example, any code-hosting platform must exercise caution when returning executables or source archives as application/octet-stream, because there is a risk they may be misinterpreted as HTML and displayed inline.

The text/plain logic subsequently implemented in Internet Explorer and Safari in order to detect HTML in such a case is really bad news: It robs web developers of the ability to safely use this MIME type to generate user-specific plaintext documents and offers no alternatives. This has resulted in a substantial number of web application vulnerabilities, but to this day, Internet Explorer developers seem to have no regrets and have not changed the default behavior of their code.

Site uses X-Content-Type-Options:nosniff. Author says the following about this header:

The use of this header [X-Content-Type-Options] is highly recommended; unfortunately, the support for it [...] has only a limited support in other browsers. In other words, it cannot be depended on as a sole defense against content sniffing.

What content sniffing attacks X-Content-Type-Options:nosniff doesn't prevent? What Content-Type should be returned to user instead of text/plain?

Community
  • 1
Andrei Botalov
  • 5,267
  • 10
  • 45
  • 73

3 Answers3

24

Background. X-Content-Type-Options: is a header that is designed to defend against MIME content-sniffing attacks. MIME content-sniffing attacks are a risk when you allow users to upload content (e.g., images, documents, other files) to your website, where they can be downloaded by other users.

As @Rook says, this has nothing to do with eavesdropping/capturing network traffic.

What attacks doesn't it prevent? Because X-Content-Type-Options: is only supported on some browsers, it does not protect attacks against users who use other browsers. In particular, it is supposed on IE, Chrome, and Firefox 50. See also What are the security risks of letting the users upload content to my site? for some other attacks it doesn't prevent, e.g., uploading of malware or unsavory content, uploading of content that exploit a vulnerability in the user's browser, etc.

What content type should be returned? You should return the appropriate content type for that file. You should not allow users to upload untrusted content with dangerous content types. For more details, please see the answers to the following questions:

  1. Is it safe to serve any user uploaded file under only white-listed MIME content types?

  2. Is it safe to store and replay user-provided mime types?

  3. MIME sniffing protection

  4. Why should I restrict the content type of files be uploaded to my site?

  5. What are the security risks of letting the users upload content to my site?

  6. How can I be protected from pictures vulnerabilities?

  7. Using file extension and MIME type (as output by file -i -b) combination to determine unsafe files?

This topic has been extensively discussed and documented elsewhere on this site, so I'm not going to try to repeat all of the useful advice found there.

Update: I just learned that setting the Content-Type and X-Content-Type-Options headers appropriately is 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 whitelisting of file content types 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
  • Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/29777/discussion-on-answer-by-d-w-does-x-content-type-options-really-prevent-content). – Rory Alsop Oct 01 '15 at 16:35
6

Here is an answer of Michal Zalewski received by email:

The short answer is that it works in MSIE, and only in some specific cases. It won't protect you against (much less zealous) sniffing in most other browsers; but more importantly, won't discourage plugins from doing things such as the crossdomain.xml risk outlined above; and won't necessarily prevent subresource loads with mismatched MIME types (i.e., loading an image as application/x-shockwave-flash via <embed>).

Andrei Botalov
  • 5,267
  • 10
  • 45
  • 73
3

What sniffing attacks X-Content-Type-Options:nosniff doesn't prevent?

Sniffing by tools that don't know about X-Content-Type-Options: some browsers, and plugins that can fetch network resources. (For example historically Java GIFAR, Flash loadPolicyFile...)

What Content-Type should be returned to user instead of text/plain?

There is no good answer to that, so if you need to host untrusted text files you should take the usual mitigation of hosting them on a separate hostname (and ideally IP address).

Alternative: HTML-encode, add a <pre> and serve as text/html.

bobince
  • 12,494
  • 1
  • 26
  • 42
  • Why should untrusted files be hosted on separate IP address? I haven't heard about such attacks previously. Could you supply some resources to read about it? – Andrei Botalov Mar 20 '12 at 12:45
  • 4
    @Andrey: The Java Same Origin Policy is based on the storage location of the class instead of the location of the containing document, and is partially IP-based instead of host-based. So if someone can sneak a file with contents parsable as a JAR/ZIP onto your server, they can use it as an applet to have users' browsers send arbitrary TCP connections to the server. Worse, in older versions of Java, you can send arbitrary URLConnections with the user's credentials, giving you free rein to do XSRF attacks against other sites on the same IP. – bobince Mar 20 '12 at 14:00
  • @bobince And what if Java Same Origin Policy has a bug? – Pacerier Jul 13 '12 at 02:26
  • @Pacerier: then Oracle will patch it... hopefully with some speed because a same origin policy bug can lead to universal cross-site-scripting. – bobince Jul 13 '12 at 08:04
  • @bobince Does Flash and silverlight have Same Origin Policy too? – Pacerier Jul 13 '12 at 09:09
  • @Pacerier: yes. Flash, similar to Java, considers the site hosting the SWF file to be its Origin. Silverlight considers the URL of the page hosting the plugin to be its Origin, which is much more consistent with the JavaScript SOP. – bobince Jul 13 '12 at 09:16
  • @bobince Ic, besides tricking the browser into thinking the file is java/flash/silverlight/HTML, are you aware of some other file types that may lead the browser to do code execution? – Pacerier Jul 13 '12 at 10:12