MSIE facilitates Cross Site Scripting
Chris Smith and me were investigating a strange Internet Explorer related problem in the last two days and it looks like IE has a flaw that makes cross site scripting on many sites possible.
The initial problem were spammers using open wikis to upload text files containing spammy HTML. At first we didn't understand why they would do that, as .txt files are served with a text/plain mime type and thus shouldn't be rendered by any browser. Well, we soon found that this is true for every browser, except for the Internet Explorer.
You probably know that on the web each served document or file is accompanied by a Content-Type header which tells the browser what type of data it is receiving. The browser then is supposed to use this info to decide what to do with the data, eg. rendering the HTML, downloading the file or give the data to a plugin.
So if a browser does not get a mime type registered for rendering HTML (usually text/html) it should not render it as HTML.
Well, Microsoft thought different and implemented something they call MIME Type Detection. It means they use the first few hundred bytes of the data and try to guess what the content is. This is a nice idea and even mentioned in RFC 2616:
If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content […]
Unfortunately Microsoft got the order somehow tangled up: They ignore the sent type and do their guessing first. This of course violates the RFC, but is a well known fact: Phil Ringnalda wrote about it in 2004.
So how does that facilitate Cross Site Scripting? IE treats nearly everything1) as HTML that contains some tags in the first few hundred bytes. This includes the <script> tag.
Many web applications won't let you upload HMTL or JavaScript files to prevent XSS. But images or PDF documents for example aren't considered harmful and are often allowed. Yet I was able to construct such files with script code embedded which is executed by Internet Explorer.
Don't believe it? Here is a link to a 1x1 pixel white PNG image. Open it in Firefox or any other decent browser. It will be displayed fine. IE will treat it as HTML because it contains a script tag in the image comment. Note that this is a perfectly valid PNG image which I created in Gimp.
The next test object is a modified, simple "Hello World" PDF file. The Acrobat reader displays it fine2). Following the link in IE will execute the JavaScript.
So what does this mean? Wherever you allow upload of “harmless” files you might open a XSS vulnerability which could lead to IE user accounts compromised.
The solution? Hell, I don't know. We're still wondering about what we should do in DokuWiki about this. For now I recommend not allowing anonymous upload of any files.
PS: I tested the above files with MSIE 6.0.2900.2180.xpsp_sp2_gdr.050301-1519 on Windows XP. From different tests yesterday I know for sure that the same mime type guessing is still used in IE7. If the specific flaws shown above still exist I cannot say, but I guess so.
1
2
3<?php
$tags = array('a','abbr','acronym','address','applet','area','b','base','basefont','bdo','big','blockquote','body','br','button','caption','center','cite','code','col','colgroup','dd','del','dfn','dir','div','dl','dt','em','fieldset','font','form','frame','frameset','h1','h2','h3','h4','h5','h6','head','hr','html','i','iframe','img','input','ins','isindex','kbd','label','legend','li','link','map','menu','meta','noframes','noscript','object','ol','optgroup','option','p','param','pre','q','s','samp','script','select','small','span','strike','strong','style','sub','sup','table','tbody','td','textarea','tfoot','th','thead','title','tr','tt','u','ul','var','xml','!DOCTYPE');
if (isset($_GET['tag']) && in_array($_GET['tag'], $tags))
{
header('Content-Type: image/png');
echo urldecode('%89PNG%0D%0A%1A%0A'), // Fake a PNG beginning
'<', $_GET['tag'], // Fake a start tag
'*'; // If empty, IE don't detect any tag
}
else
{
foreach ($tags as $tag)
{
echo '<iframe src="test.php?tag=', $tag, '" width="50" height="20" marginwidth="0" marginheight="0" scrolling="no"></iframe>';
}
}
4Just put it in a file nammed test.php, and run it with IE :
<?php
$tags = array('a','abbr','acronym','address','applet','area','audioscope','b','base','basefont','bdo','bgsound','big','blackface','blink','blockquote','body','bq','br','button','caption','center','cite','code','col','colgroup','comment','custom','dd','del','dfn','dir','div','dl','dt','em','embed','fieldset','fn','font','form','frame','frameset','h1','h2','h3','h4','h5','h6','head','hr','html','i','iframe','ilayer','img','input','ins','isindex','keygen','kbd','label','layer','legend','li','limittext','link','listing','map','marquee','menu','meta','multicol','nobr','noembed','noframes','noscript','nosmartquotes','object','ol','optgroup','option','p','param','plaintext','pre','q','rt','ruby','s','samp','script','select','server','shadow','sidebar','small','spacer','span','strike','strong','style','sub','sup','table','tbody','td','textarea','tfoot','th','thead','title','tr','tt','u','ul','var','wbr','xml','xmp','!DOCTYPE', '!--');
if (isset($_GET['tag']) && in_array($_GET['tag'], $tags))
{
header('Content-Type: text/plain');
echo str_repeat(' ', 10), // Some white space
'<', $_GET['tag'], // Fake a start tag
'>'; // Random string. If empty, IE won't detect any tag
}
else
{
foreach ($tags as $tag)
{
echo '<iframe src="test.php?tag=', urlencode($tag), '" width="50" height="50" marginwidth="0" marginheight="0" scrolling="no"></iframe>';
}
}
5
6
7
8I've set IE's security to the maximum and it just displayed the PNG source in plain text.
I couldn't test the PDF since it didn't allow me to download it.
On the other hand, the XSS bug in IE still persists when its security is set to normal.
Both the PNG and PDF javascripts were executed !
9Luckily - Microsoft creates secure products like SharePoint which have built in XSS vulnerabilities due to issues like this one.
10See http://blogs.msdn.com/ie/archi … 64581.aspx
But even with this "fix" IE will prompt the client to open, save, cancel. If the document is an html document and doesn't end in one of Microsofts known extensions(.gif,.jpg,.exe,.pdf,...) or no extension at all and the client then selects open, ie will open the document in the application space and not from the local hard drive and therefore will allow the XSS attack.
See http://seclists.org/webappsec/ … /0034.html
11the nasty part is that images retain the attack even after resize/crop/whatever, and can be perfectly normal. and the attack code can load image itself here again :)
Hi, I'm Andreas Gohr and splitbrain.org is my website.I'm a Web, Wiki and Open Source enthusiast living in Berlin, Germany. Enjoy your stay here.
