Safari for Windows employed unsafe content-sniffing behavior on pages
that were served up as
text/plain. As a result, an attacker could
cause cross-site scripting to occur in locations that would not normally
be vulnerable. This issue was fixed in Safari 5.1. It has been assigned
the identifier CVE-2010-1420.
How Did It Work?
When web pages were served up with a
text/plain content type, Safari
for Windows would determine the correct content handler by looking at
their file extension. For instance, a
text/plain document located at
http://example.com/file.html would be parsed as HTML rather than
rendered as text. In most other browsers, a text/plain content type
precludes the content from ever being handled as HTML (IE being the exception).
Of course, that behavior is not very interesting by itself. Most URIs
that serve up content as
text/plain don’t also have HTML file
extensions. However, in certain cases it’s possible to append data to
the path portion of the URI without changing how the request is routed.
In those cases it was possible to exploit this content-sniffing behavior
by appending a filename with an HTML extension. It was also possible to
cause cross-site scripting when user-controlled content was served up in
The simplest example is PHP’s support for
PATH_INFO. By default,
most PHP installations allow arbitrary data to be appended to the path
portion of the URI; the portion of the path after the file itself is
$_SERVER['PATH_INFO']. So, just about any PHP script that
serves up content as
text/plain could also be used to exploit this vulnerability.
I set up a script, located at http://sandboxing.me/poc/b82553b2869b7fa80766ec55073e998a.php, as a demonstration. The code is as follows:
1 2 3 4 5 6 7 8 9 10
<?php header('Content-type: text/plain'); ?> <?php header('X-Content-Type-Options: nosniff'); ?> <html> <head> <title>Test</title> </head> <body> <script>alert(1);</script> </body> </html>
I included the X-Content-Type-Options header for completeness, since it’s used by IE to override similar insecure content-sniffing behavior. As expected, Safari for Windows ignored the header.
To use the script for testing, I simply appended a forward slash to the URL, followed by a filename. Safari used the newly provided extension to determine how the file contents were parsed. Some examples:
What about OS X?
Safari for OS X did not exhibit the same behavior: in fact, it appears that similar behavior was patched in 10.4.4 (see http://www.mnot.net/blog/2006/01/11/safari_content_sniffing).
Bug 637981, which was recently patched in Bugzilla, relies upon this
content sniffing behavior. Raw user-supplied content (in the form of an
attached patch file) was being served as
text/plain from the main
Bugzilla domain. By uploading a malicious patch file, it was possible to
I would like to thank Apple Product Security for handling my report and keeping me in the loop as the issue was patched. I also want to acknowledge Hidetake Jo, who discovered this vulnerability independently.