Mitigate the security risks that come from IE, Chrome and other browsers trying to sniff the mime type

Summary of "IE's stupid content sniffing behavior": IE will render some files as different types than the extension suggests (e.g. a .txt file might be rendered as an image or HTML file).

Any progress?

subscribing

I don't think we should really rely on the what browsers like to respect or not. One browser does, the other doesn't.
We should at least make sure validation hooks are available to allow contrib to double-check the data. That might include this reverse-engineered IE-code.

we were facing same problem with a large enterprise customer.
I think the solution should be inherent to Drupal core, and it is rather simple to solve most of it.
The rest 0.01% might need some special care.

Solution:
in upload module when validating uploaded images:
- if the file is 'txt' - make sure it does not contain HTML and if so do not pass validation
- if the file is an image (gif/jpeg) - call getimagesize() function to see if it is a real image. if False returned - do not allow it

This simple patch will solve this. And if I missed some scenario, it is easily added in the right place, where everyone using Drupal will be able to enjoy it without patching the .htaccess file.

- if the file is 'txt' - make sure it does not contain HTML and if so do not pass validation

That doesn't seem like a solution to me. It seems perfectly fine for a text file to contain a mix of different content including HTML.

If someone wants to implement content verification, let's not reinvent the wheel. Use the IEContentAnalyzer class from MediaWiki.

http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/libs/IEC...

This can be easily implemented as a contrib module, let's bump this as a possible feature request for 8.x.

+++ b/core/lib/Drupal/Core/EventSubscriber/FinishResponseSubscriber.php
@@ -96,6 +96,10 @@ public function onRespond(FilterResponseEvent $event) {
+    // Ask browsers not to sniff the content, since that can lead to
+    // XSS and other vulnerabilities
+    $response->headers->set('X-Content-Type-Options', 'nosniff', FALSE);

It would be great to link to some resource where this header is explained.

Makes sense to me.

This incremental change makes sense to me. Seems like a nice addition.

I filed #2400087: D7 port of 462950 - Mitigate the security risks that come from IE and other browsers trying to sniff the mime type to get this into a d7 environment so we can get broader testing just in case this doesn't get backported (or not quickly).

The implementation turned out not to be a feature. Given that facebook and google use this I think it makes sense.

This issue is a major task that will improve security and the disruption it introduces is limited. Per https://www.drupal.org/core/beta-changes, this is a good change to complete during the Drupal 8 beta phase.

Committed 1f380a6 and pushed to 8.0.x. Thanks!

Rerolled patch #23.

Now with the right extension

That test is working in my local install. Is that an issue with the test bot?

ok, so this is technically Reviewed and Tested By the Community but not Ready To Be Committed, until we fix the bot.

Should we create a separate issue for the bot somewhere?

Otherwise, we can also commit it without the test. Tests can be added later but shouldn't delay a security improvement imho

Agree, lets do it.

Didn't want to hide D8 patch

Committed to 7.x - thanks!

I'm not sure if "Header always set" will break Apache 1.x, but we may have reached the point where we officially stop caring :)

Question, though - we are setting this header on uncached page requests, but not on cached ones - is that an oversight? Leaving the issue open for that, for now.

I also fixed this on commit (not sure why the code comment from Drupal 8 wasn't backported):

diff --git a/includes/bootstrap.inc b/includes/bootstrap.inc
index 5504c38..b2f2b04 100644
--- a/includes/bootstrap.inc
+++ b/includes/bootstrap.inc
@@ -1262,6 +1262,9 @@ function drupal_page_header() {
   $default_headers = array(
     'Expires' => 'Sun, 19 Nov 1978 05:00:00 GMT',
     'Cache-Control' => 'no-cache, must-revalidate, post-check=0, pre-check=0',
+    // Prevent browsers from sniffing a response and picking a MIME type
+    // different from the declared content-type, since that can lead to
+    // XSS and other vulnerabilities.
     'X-Content-Type-Options' => 'nosniff',
   );
   drupal_send_headers($default_headers);

Removing tag - this doesn't have a change record, and probably doesn't need one actually.

This seems to have been added to Drupal 7.40 as an apache mod_headers directive

Header always set blah

Why was it not a Header merge blah?

Drupal module seckit allowed setting this header and now you wind up with

X-Content-Type-Options: nosniff, nosniff

in the headers. A merge still sets the header if it is not set.

A mixture of

Server version: Apache/2.2.15 (Unix)
Server version: Apache/2.4.12 (Red Hat)

merge works fine for me.

I can confirm that as of Drupal 7.40, every page has the following response header included:
X-Content-Type-Options: nosniff, nosniff

The problem that the nosniff value is set twice to the X-Content-Type-Options header originates by the following addition to the .htaccess file:

Header always set X-Content-Type-Options nosniff

The problem in the above Apache directive is the always condition. That must be removed, so the directive reads

Header set X-Content-Type-Options nosniff

I am using Apache 2.2.15 from a stock CentOS 6. No need to change the action from set to merge.

Here is the patch that solves the problem mentioned in #47.

This issue still needs to be RTBC.

And, keeping the the always condition results in

X-Content-Type-Options: nosniff, nosniff

, right?

It's really hard to follow re-opened issues both in terms of history on d.o and also git commits logs.

I've opened #2633204: (followup) Mitigate the security risks that come from IE, Chrome and other browsers trying to sniff the mime type for the follow-up work. Moving this back to 7.x and fixed.

Restoring priority.

It looks like this feature completely broke my installation on openSUSE 11.4: For every js file I am getting now Chrome errors like "Refused to execute script from '<>/misc/drupal.js?o0epsk' because its MIME type ('text/x-js') is not executable, and strict MIME type checking is enabled."

I edited the file /etc/apache2/mime.types - commented out "text/x-js js" entry there and restarted Apache, but that did not help - I am still getting all these errors for js files. What do I have to do?

The openSUSE reference suggests editing mod_mime-defaults.conf.

Apparently, clearing Chrome caches was important for my change on the server to be recognized: it kept the old mime types way after I modified them on the server in the file /etc/apache2/mime.types and rebooted the server.

Thanks for the patch on #48

I got similar MIME issue with Chrome trying to load any kind of files. Any patch posted here worked in my case, so I opted to remove this part of code 'X-Content-Type-Options' => 'nosniff', in includes/bootstrap.inc. I'm using Drupal 7.43

@alexito By doing so you have reduced the security of Drupal.

Question, though - we are setting this header on uncached page requests, but not on cached ones - is that an oversight?

Looks like this is now being addressed at #2819535: x-content-type-options nosniff ignored for anonymous cached pages.

Follow-up #2633204: (followup) Mitigate the security risks that come from IE, Chrome and other browsers trying to sniff the mime type is superseded by #2854817: Duplicate X-Content-Type-Options headers both with the value nosniff.