![Announcement icon Announcement icon](https://www.drupal.org/files/styles/grid-2-2x-square/public/announcements/drupal-evergreen-logo-280X280px%20%281%29_0.jpg?itok=PHpn6rCb)
There is now available a PHP library to mimic IE's stupid content sniffing behavior.
http://tstarling.com/blog/2008/12/secure-web-uploads/
It's possible that we should either use this code, or make sure that validation hooks are available to allow contrib to use such code to block uploads.
Comment | File | Size | Author |
---|---|---|---|
#61 | core-mime-fix_nosniff-462950-61.patch | 433 bytes | afsch |
#48 | remove_always_condition-462950-48.D7.patch | 734 bytes | roball |
#35 | 462950-35.patch | 854 bytes | Pere Orga |
#17 | 462950-17.patch | 2.79 KB | pwolanin |
![Acquia logo](/files/ads/acquia-issue-sponsorship.png)
Comments
Comment #1
sreynen CreditAttribution: sreynen commentedSummary 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).
Comment #2
PanchoAny progress?
Comment #3
jbrown CreditAttribution: jbrown commentedsubscribing
Comment #4
pwolanin CreditAttribution: pwolanin commentedInstead we should perhaps add the "nosniff" header that IE8+ is supposed to respect
http://htaccess.wordpress.com/2009/09/22/x-content-type-options-nosniff-...
http://blogs.msdn.com/b/ie/archive/2008/09/02/ie8-security-part-vi-beta-...
Comment #5
pwolanin CreditAttribution: pwolanin commentedComment #6
pwolanin CreditAttribution: pwolanin commentedWe would need to change the core .htaccess file to check if mode_headers is enabled and then add the nosniff header when serving static content (or all content?)
http://httpd.apache.org/docs/2.2/mod/mod_headers.html#header
Comment #7
PanchoI 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.
Comment #8
noamdanon CreditAttribution: noamdanon commentedwe 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.
Comment #9
gregglesThat 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.
Comment #10
Damien Tournoud CreditAttribution: Damien Tournoud commentedIf 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.
Comment #11
pwolanin CreditAttribution: pwolanin commentedrelated: https://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flash/
This flash vuln would have been block by nosniff
see also: https://www.owasp.org/index.php/List_of_useful_HTTP_headers
Comment #12
pwolanin CreditAttribution: pwolanin commentedquick 1st pass
Comment #13
dawehnerIt would be great to link to some resource where this header is explained.
Comment #14
pwolanin CreditAttribution: pwolanin commentedhow about this?
Comment #15
pwolanin CreditAttribution: pwolanin commentedShould probably add a test that at least verifies the header is set any time PHP serves the response?
Comment #16
gregglesMakes sense to me.
Comment #17
pwolanin CreditAttribution: pwolanin commentedHere's a small added test, and fix the htaccess directive
Comment #18
gregglesThis 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).
Comment #19
pwolanin CreditAttribution: pwolanin commentedWell, let me see about rolling a Drupal 7 version - it should be easy, but we can use that other issue for now to run the tests.
Comment #20
alexpottThe 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!
Comment #21
alexpottComment #23
pwolanin CreditAttribution: pwolanin commentedcopying the patch over from the other issue. Not sure why it fails. There is something funny about testbot compared to local results for me.
Comment #25
xjmComment #28
Pere OrgaRerolled patch #23.
Comment #29
Pere OrgaNow with the right extension
Comment #32
Pere OrgaThat test is working in my local install. Is that an issue with the test bot?
Comment #33
pwolanin CreditAttribution: pwolanin as a volunteer and at Acquia commented@Pere Orga - that's the same question I had in #23 - passed locally but not on the bot
Comment #34
Pere Orgaok, 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?
Comment #35
Pere OrgaOtherwise, we can also commit it without the test. Tests can be added later but shouldn't delay a security improvement imho
Comment #36
Fabianx CreditAttribution: Fabianx as a volunteer and at Tag1 Consulting commentedAgree, lets do it.
Comment #37
Pere OrgaDidn't want to hide D8 patch
Comment #38
pwolanin CreditAttribution: pwolanin as a volunteer and at Acquia commentedThis is actually critical, since Chrome is affected too in some cases.
Comment #39
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedComment #41
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedCommitted 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):
Comment #42
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedRemoving tag - this doesn't have a change record, and probably doesn't need one actually.
Comment #43
pwolanin CreditAttribution: pwolanin as a volunteer and at Acquia commented@David_Rothstein
I think the headers are added to the cache and should be added by drupal_serve_page_from_cache():
Comment #44
kaosagnt CreditAttribution: kaosagnt commentedThis 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.
Comment #45
pwolanin CreditAttribution: pwolanin as a volunteer and at Acquia commentedThe docs claims it will replace the value:
http://httpd.apache.org/docs/2.2/mod/mod_headers.html
what apache version are you using?
Comment #46
kaosagnt CreditAttribution: kaosagnt commentedA mixture of
Server version: Apache/2.2.15 (Unix)
Server version: Apache/2.4.12 (Red Hat)
merge works fine for me.
Comment #47
roball CreditAttribution: roball commentedI 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 theX-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 readsHeader 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
tomerge
.Comment #48
roball CreditAttribution: roball commentedHere is the patch that solves the problem mentioned in #47.
Comment #50
pwolanin CreditAttribution: pwolanin as a volunteer and at Acquia commentedThis change looks reasonable, but we should make it for Drupal 8 also?
Comment #51
roball CreditAttribution: roball commentedThis issue still needs to be RTBC.
Comment #52
pwolanin CreditAttribution: pwolanin as a volunteer commentedSo I'm seeing the opposite problem in Drupal 7 and 8, if I take out the "always" I get 2x nosniff header lines like:
Comment #53
roball CreditAttribution: roball commentedAnd, keeping the the
always
condition results inX-Content-Type-Options: nosniff, nosniff
, right?
Comment #54
catchIt'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.
Comment #55
Fabianx CreditAttribution: Fabianx as a volunteer and at Tag1 Consulting commentedRestoring priority.
Comment #57
calmforce CreditAttribution: calmforce commentedIt 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?
Comment #58
cilefen CreditAttribution: cilefen commentedThe openSUSE reference suggests editing mod_mime-defaults.conf.
Comment #59
calmforce CreditAttribution: calmforce commentedApparently, 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.
Comment #60
dolphinonmobile CreditAttribution: dolphinonmobile as a volunteer commentedThanks for the patch on #48
Comment #61
afschI 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.43Comment #62
cilefen CreditAttribution: cilefen commented@alexito By doing so you have reduced the security of Drupal.
Comment #63
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedLooks like this is now being addressed at #2819535: x-content-type-options nosniff ignored for anonymous cached pages.
Comment #64
Wim LeersFollow-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.