If you look at RSnake XSS cheat sheet http://ha.ckers.org/xss.html you will notice that the following:
<IMG SRC="javascript:alert('XSS')"
<IMG SRC=javascript:alert("XSS1")>
<IMG SRC=`javascript:alert("XSS")`>
<IMG SRC=javascript:alert(String.fromCharCode(88,83,83,88))>
<IMG SRC="jav ascript:alert('XSS');">
<INPUT TYPE="IMAGE" SRC="javascript:alert('XSS');">
<BODY BACKGROUND="javascript:alert('XSS')">
and many other XSS strings listed on the cheat sheet are not working on IE7, ie: you won't get javascript code executed, in fact MS says that they disabled javascript: and vbscript: URLs from some contexts (http://blogs.msdn.com/dross/archive/2008/03/10/xss-focused-attack-surface-reduction.aspx)
If you build an HTML page with the above XSS strings you will find out that the script code doesn't get executed when the HTML page is opened with IE7 but it's only true in some basic scenarios. Actually those kind of URLs (javascript: and vbscript:) continue executing normally when you load the web page in a new tab, new window, in a Frame and in an IFrame.
Doing a quick reverse engineering it can be seen that when a web page is loaded in a Frame, IFrame, new window or new tab the execution path is a bit different in IE than when you simple load a HTML page. Basically it seems MS forgot to patch some code paths in this case (not the first time, http://www.argeniss.com/research/MSBugPaper.pdf) so you get a different behaviour in different scenarios. I wonder if other stuff could be bypassed in this way, who knows, it's needed more time to look deeper.
Btw, The same happens in IE8 beta2.
This is not big deal nor a security vulnerability but it shows how difficult could be to completely disable/remove functionality in a complex application such as Microsoft Internet Explorer
No comments:
Post a Comment