MIME Sniffing is a technique implemented by IE >= 4.0 allowing the browser to dynamically guess the content type of downloaded files. Basically the browser analyzes the magic bytes of any downloaded file and decides whether to trust the servers transmitted content type or use its own guess. Suppose a malicious author uploads a paper to a site in PostScript format. By carefully crafting the paper, the author can create a chameleon document that both is valid PostScript and contains HTML (see Figure 1). The site accepts the chameleon document as PostScript, but when a reviewer attempts to read the paper using Internet Explorer 7, the browser’s content-sniffing algorithm treats the chameleon as HTML, letting the attacker run a malicious script in the sites security origin. What IE does is, if there is a mismatch between the content type of the server and the one defined by the magic bytes, then it uses its own content type guess.
The problem arises once a website allows users to upload content which is then published on the web server. If an attacker manipulates the content in a way to be accepted by the web app and rendered as HTML by the browser, it is possible to inject code in e.g. an image file and make the victim execute it by viewing said image.
Is this a paper or a web page?A chameleon PostScript document %!PS-Adobe-2.0 %%Creator: <script> ... </script>What happens if IE decides it is HTML?
If during the graphic files management there are characters, which are non relevant for the managed file, then a process that analyses this data and compares the resulting signatures with the signatures of the supported formats is launched.If the appropriate format is found, the browser begins to manage the file in accordance with this format.
The following example will illustrate this. We have the PNG file consisting of a one black dot. Pic. 1. The source PNG file Naturally, if we open this image in the browser we will just see a black dot. However, if we add the well‐known string (in hexadecimal codes) <script>alert(‘Image XSS’)</script> to the end of the graphic file and open it in Internet Explorer, the browser, after having processed the image, will find the segment of data, which is not the part of the image and will process it as HTML. This will execute our script in the browser. Pic. 2. Modified graphic file
For example, you can send a letter to a user from mail.ru server with a picture attached. If the recipient clicks Show Picture, the script added to the image file will be executed and will, for instance, send the recipients cookie to the hackers e‐mail. The result that the script implemented to the image (in mail.ru) will give is shown on the picture 3. The script simply displays users cookie on the screen, demonstrating that access to the victims cookie can be gained.
There are several means of protecting your application from these type of attacks. If dealing with images, use something like the Image Magick tools to resize or recompress the uploaded images prior to serving them. Any of these operations will remove the attack code. Microsoft also introduced several HTTP headers to disable content sniffing in IE 8: To force the browser to trust the servers content type, use the following additional HTTP header: X-Content-Type-Options: nosniff
There are actually 2 things to do here. Step 1. When serving resources, make sure you send the content- type header to appropriately match the type of the resource being served. For example, if you’re serving an HTML page, you should send the HTTP header: Content-Type: text/html; Step 2. Add the X-Content-Type-Options header with a value of “nosniff” to inform the browser to trust what the site has sent is the appropriate content-type, and to not attempt “sniffing” the real content-type. Adding this additional header would look like this: X-Content-Type-Options: nosniff
Wikipedias approach A good idea as a 2nd line of defense. Use a separate (sub)domain to host your user-uploaded content. With this approach you ensure, that none of the scripts that might potentially be included in the content, are executed in the context of your web application and therefore dont have access to session cookies, etc.
Gmail Product: Gmail.com Setup: Windows XP SP3 with IE 7.0 (Google Chrome frame installed) Vulnerability: XSS possible using malicious Image as attachment(works for IE6/7) The vulnerability was in www.gmail.com used to send Emails. Ability to send images as attachments to any user. By creating malicious image file and attaching it to mail attacker can exploit this vulnerability which can lead to complete compromise of account by stealing mail receiver cookies. Gmail was not validating contents of uploaded image files which can lead to XSS by including java scripts in image files. Following are screen shots which demonstrates the complete attack vector.