Prevent XSS due to MIME Type Sniffing bugs in old Internet Explorer

[Tom Reynolds]

Internet Explorer 7 and older (actually later versions, too, but less bad there) had a 'convenience feature' where they used MIME Type Sniffing to determine what to render content as. The idea there was to work around issues introduced by overpaid sysadmins who had web servers configured to return content with incorrect (or just unknown, to the web browser) MIME types. So instead of just trusting those HTTP response headers, Internet Explorer would second guess the file type of every downloaded image, and then render it based on what it decided the real file type was.

Worse than that, it sometimes got it wrong. If a file hosted on a web server with a .PNG extension was really a .JPG image, but the Response header would state "Content-Type: image/png" then instead of not rendering the image, or attempting to render it as PNG, it would try to render it as JPG, fail to do so, and instead display the binary content as rendered HTML.

And if this file contained any actual HTML code, such as <script>alert(3)</script>, it would execute this code.

Here's an example (a JPG file with a HTML-like comment, returned as "Content-Type: image/png" due to its .png file extension):
http://launchpadlibrarian.net/432443293/test-logo2.png

Accessing this using Internet Explorer 7 or older would trigger a Javascript alert popup. This can be tested using the online web browser rendering service at https://netrenderer.com

At some point Microsoft realized they might be overdoing it slightly, so (instead of fixing the issue, which they actually did later but forgot to mention it in their release notes) they made Internet Explorer react to the non-standard "X-Content-Type-Options: nosniff" HTTP header, which, if set, would disable the excessive guessing.

https://blogs.msdn.microsoft.com/ie/2010/10/26/mime-handling-changes-in-internet-explorer/

This may not actually help with older Internet Explorer versions (7 and below), though, so if you would like to help those versions not exploit their users (assuming there are any left - let us hope that is not the case - or check web server access logs), Launchpad could do the MIME type sniffing during upload of such user contributed content (which you thankfully host on a separate domain name), forcing the file extension and later, when requests are made to retrieve this content, the the Content-Type, to be that of the actual file.

As a reminder, currently I am able to upload a user avatar in JPG format with a .png file extension, which the web server returns as "Content-Type: image/png". Which is a bit wrong, but not much of an issue on any current, sane, web browser.

This is not actually a security vulnerability in Launchpad, so I am not filing it as such. If you should choose not to act upon this report, I will not be disappointed, but hope you enjoyed the story.

[Colin Watson (cjwatson)]

(You probably know this already, but just for the record, the librarian does already send "X-Content-Type-Options: nosniff".)

We do in fact already attempt to do MIME type detection at upload time, using https://zopecontenttype.readthedocs.io/en/latest/api.html#determining-content-types. Unfortunately this just uses https://docs.python.org/2/library/mimetypes.html#mimetypes.guess_type in the case of binary files, and that's just based on the file name.

I think using more robust sniffing would be possible, but we absolutely wouldn't want to maintain such code ourselves. https://pypi.org/project/z3c.sharedmimeinfo/ looked initially promising but it only ever had a single release, namely in 2009, so that doesn't seem like a good idea. https://pypi.org/project/filetype/ looks like it might be a better bet, but I haven't looked into it in much detail.