How to disable nosniff support?

[zippy72]

Hi,

The new nosniff support hit me this morning and it's causing me heaps of trouble.

Turns out nosniff breaks Microsoft TFS, big time. Unfortunately, I rely on TFS for most of my job.

Is there a way to disable nosniff support?

Thanks

[Moonchild]

No, there isn't. This is an essential security measure.
If Microsoft TFS sends the X-Content-Type-Options: nosniff header, they MUST make sure that their MIME types with responses actually match script content.
If they can't promise matching MIME types, then they should not send the response header.

[Isengrim]

I'm also seeing a number of problems on my work's MS SharePoint site, due to the nosniff update.

Interestingly, if I refresh the page, occasionally the missing elements will appear correctly. Some kind of timing issue, maybe?

[zippy72]

OK, I think I will have to revert to 27.6 then.

I get that it's an essential security feature, but it's also a new thing. Some way of bypassing it for broken things (which are nearly always Microsoft, let's face it) would be nice though.

[Moonchild]

I don't want to add a bypass for this because it would be analogous to setting up a passport check point by order of the government (sending the header) and then deciding to let people without a valid passport pass anyway.

X-Content-Type-Options: nosniff is not new, but even if it was, this header will ONLY be sent if a server operator explicitly sets their server up to do so. If a server operator does that, they run the risk of browsers blocking content if it doesn't follow their own imposed rules. Either send the header and have your stuff in order, or don't send the header -- but don't make it the client's responsibility to work around it.

[zippy72]

OK, so I had a look using Fiddler and I'm not quite sure that that's the whole story.

The first thing TFS is doing is a challenge-response header, which is sending a some HTML, type text/html and an error code of 401.

Fiddler isn't showing a second attempt to retrieve from IIS, so I can only assume that it's this 401 that's tripping off the nosniff protection. Basically I can repeatedly refresh the page, and the one or two that get loaded after the first challenge-response will load. If I try and reload the page about 20 or 30 times, eventually they will all turn into "304 not modified". Each time four or five scripts get through, but that is about it.

[Isengrim]

OK, so I had a look using Fiddler and I'm not quite sure that that's the whole story.

The first thing TFS is doing is a challenge-response header, which is sending a some HTML, type text/html and an error code of 401.

Fiddler isn't showing a second attempt to retrieve from IIS, so I can only assume that it's this 401 that's tripping off the nosniff protection. Basically I can repeatedly refresh the page, and the one or two that get loaded after the first challenge-response will load. If I try and reload the page about 20 or 30 times, eventually they will all turn into "304 not modified". Each time four or five scripts get through, but that is about it.

This is the same behavior I was seeing earlier. I'll do some more testing later to verify.

I also saw that the content being blocked on my site included (among other things) knockout.3.3.0.debug.js, the debug version of a fairly common js library. The response header indicates that the content is of type "application/javascript", which seems correct to me.

How does Pale Moon check whether a MIME type matches what the server claims it is when the nosniff option is being honored?

[JustOff]

I'm the one who was involved in the implementation of X-Content-Type-Options: nosniff support (Issue #1343, Issue #1488). Can anyone provide a specific example of a site on which you think it's working incorrectly?

[Isengrim]

Unfortunately, the site I'm having issues with is a MS SharePoint site which requires a login that I won't be able to provide.

[Moonchild]

I'm the one who was involved in the implementation of X-Content-Type-Options: nosniff support (Issue #1343, Issue #1488). Can anyone provide a specific example of a site on which you think it's working incorrectly?

Maybe it's more examples of empty body responses, although getting a 401 is an error and shouldn't be doing anything else. Maybe it's a better idea to just whitelist those responses that SHOULD be checked instead of blacklisting the ones that shouldn't?

[JustOff]

In any case I need a real example to investigate the issue, verify how it corresponds the standards, compare with other browsers and propose a solution. It can't be done blindly.

[Moonchild]

How does Pale Moon check whether a MIME type matches what the server claims it is when the nosniff option is being honored?

It gets it from the http channel. If "nosniff" is indicated, it will prevent the browser from sniffing the file's contents and switching to a different MIME type based on what it found the file to be, and the browser will assume that the type is what the server says it is. It may be a little confusing since the browser will still sniff the file to get the content type, but it will not USE the sniffed data to treat it as something different than what the Content-type header says it is supposed to be.

It can't be done blindly.

It can't -- but what I think the issue is here is that a 401 is returned because authorization is "not yet" provided, which is a valid response for HTTP to continue on; that response will likely not have a content-type because it's handled by the front-end, and would therefore likely be blocked with nosniff. If Microsoft software uses 401s a flag to request authorization, it may not continue with its process.

I think we can safely assume that only valid 2xx responses should ever be checked because those indicate successes and potential content to be transferred. Currently we check everything except specifically excluded codes (being redirects and content not modified).

[zippy72]

I think it's basically the 401 challenge-response from RFC 2617 that is causing the issue here. (see https://tools.ietf.org/html/rfc2617)

I've no idea where we can find an example on the net that we can validate against. The easiest would be to install a trial version of SharePoint or TFS on a VM running some flavour of Windows server. Actually, VisualSVN server might behave the same way; I will check this when I finish work.

[JustOff]

I think we can safely assume that only valid 2xx responses should ever be checked because those indicate successes and potential content to be transferred. Currently we check everything except specifically excluded codes (being redirects and content not modified).

Well, now I got it. Should we make check against the full list of 2xx codes?

[Moonchild]

Well, now I got it. Should we make check against the full list of 2xx codes?

Hmm.. not all of them would immediately return data so may not have a content type by design. It's probably best to only check on responses immediately resulting in data, i.e.: 200, 201, 203, and maybe 205 -- not sure about 206 as I'm not sure if partial content can be checked in a meaningful way (and might get false positives) -- probably best not to.

[JustOff]

Ok, then I'll probably start by trying to simulate all cases and check the behavior of other browsers.

[JustOff]

I checked the behavior of other browsers and found out that both Firefox and Chrome are performing a `nosniff` check against the full list of 2xx responses. I made a custom win32 build with the similar limitations, zippy72 and Isengrim, please check your PM for the link and report if it fixes the issue.

[Isengrim]

I tried the experimental build out on the SharePoint site I use. The content loads correctly the first time and there are no errors about content being blocked due to mismatched MIME types. I tried navigating the site and refreshing pages (using Ctrl+F5 to bypass the cache) several times. Preliminary testing indicates that all seems to work as expected. I was not able to reproduce the issues encountered on the release build.

Let me know if there's anything specific you want me to look for or test. And thank you for the quick patch.

[JustOff]

Thanks for checking, the corresponding patch was submitted to the upstream.

[zippy72]

Hi,

I can also confirm this build is working perfectly, thank you!