W3C home > Mailing lists > Public > public-webappsec@w3.org > April 2015

RE: X-Content-Type-Options: nosniff

From: David Walp <David.Walp@microsoft.com>
Date: Wed, 8 Apr 2015 17:38:33 +0000
To: Anne van Kesteren <annevk@annevk.nl>, WebAppSec WG <public-webappsec@w3.org>
Message-ID: <BN3PR0301MB13144EED3D62867408079FBA9BFC0@BN3PR0301MB1314.namprd03.prod.outlook.com>

Please, can you share which version of Internet Explorer you were working with?  Not sure if you know that in Windows 10  there has been a focus on making the browser interoperable with the actual Web.  A result of this work is a number of changes in the area you describe for the Windows 10 browser.  I wanted to know if these changes were reflected in your analysis.


>-----Original Message-----
>From: Anne van Kesteren [mailto:annevk@annevk.nl] 
>Sent: Thursday, April 2, 2015 12:42 AM
>To: WebAppSec WG
>Subject: X-Content-Type-Options: nosniff
>I've been trying to figure out what this header does in Internet Explorer 11 and Chrome dev and how we could maybe standardize it.
><script> - Internet Explorer still loads scripts with Content-Type missing and Content-Type set to the empty string. Chrome is stricter and >requires a match.
>Chrome however treats all loads as successful (dispatches load event).
>Internet Explorer does not (dispatches error event for mismatches).
>Chrome's error console incorrect labels missing Content-Type as being the empty string.
>I have not tested MIME types extensively.
>new Worker() - Internet Explorer does not load scripts with Content-Type missing or Content-Type set to the empty string this time around. >Consistently dispatches error events on the Worker instance.
>Chrome does not support nosniff here.
>importScripts() - Internet Explorer is as strict as new Worker().
>Throws "NetworkError" consistently. Chrome does not support nosniff here.
><link rel=stylesheet> - This is only relevant in quirks mode for same-origin requests as otherwise we already have strict checking for text/css as >far as I can tell from the specification. (And although this is not specified for @import and co, it should apply there too.)
>Internet Explorer does ignore the CSS due to a MIME type mismatch.
>However, it treats all loads as successful (dispatches load event).
>Not very consistent.
>Chrome does not ignore the CSS and claims Content-Type missing, Content-Type being the empty string, and Content-Type being "x", are all >instead "text/plain" in its console.
>It seems to me that ideally we treat this similar to CSP and Mixed Content in that it's a network error. Internet Explorer does not do this for CSS >currently however and I have yet to test images. Would the Internet Explorer team be open to changing how they deal with this for CSS?
>Is Chrome interested in aligning this with network error treatment for the sole case where they currently implement this (<script>)? Is Chrome >interested in widening its application?

Received on Wednesday, 8 April 2015 17:40:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:48 UTC