The document discusses content sniffing vulnerabilities in web browsers. It explains that browsers try to determine the true content type of a file, even if the server provides the wrong content type header. This allows an attacker to craft a file, like an image, that is also valid HTML containing JavaScript. When the browser content sniffs the file and treats it as HTML, the JavaScript will execute in the context of the vulnerable website. The document provides examples of how this can be used to steal cookies from users and perform cross-site scripting attacks. It recommends server and browser fixes like ensuring correct content type headers and adding headers to disable content sniffing.

3.  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 server's 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.

4.  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.

5. 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?

6. Internet Explorer treats it as HTML.

7. To mount a content-sniffing XSS attack, the attacker uploads a GIF/HTML
chameleon to Wikipedia. The browser treats the chameleon as HTML and
runs the attacker’s JavaScript.

8. 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.

9.  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

10.  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 recipient's
cookie to the hacker's 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 user's cookie on the screen, demonstrating that access to the
victim's cookie can be gained.

11.  The content-type for a given resource should match the “type” of
the resource.
 For example, an HTML page would use “text/html”, a PNG
image would use “image/png”, and a CSS document would use
“text/css”.
 However, often times, the content-type is either not specified or is
wrong.
 This has led to browsers having to implement “sniffing”
algorithms to determine what the actual data is that is being
served, and then apply the appropriate parsing and execution
semantics for the sniffed type.
 This, however, has caused certain bugs.
 As we have just seen this allows attackers to have files that were
supposedly images be interpreted as javascript and executed.

12.  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

13. 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

14. Wikipedia's 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 don't have access to session
cookies, etc.

15. 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.

17.  .

19.  This Attack was possible on IE 6/7/8/9/10 protection which was
presented in NullCon 2012.

20.  Image 1
 Image 2

21.  Image 3
 Image 4