It seems I haven't been very clear in my previous post.
I was wrong at saying that: "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." What I was trying to say is that Script URLs can still be used to exploit XSS(that's why I listed those XSS strings) when you load the web page in a new tab, new window, in a Frame and in an IFrame. What I missed is that in fact MS did some changes (and a great job) to prevent exploitation of some vulnerabilities such as http://raffon.net/research/ms/ie/crossdomain/string.html , this PoC doesn't work on IE7 and IE8 because Script URLs don't get executed in that context, this prevents some cross domain bugs or make them harder to exploit.
But Script URLs can still be used to exploit XSS, they weren't complete disabled/removed in IE7 and IE8, RSnake XSS cheat sheet http://ha.ckers.org/xss.html has to be updated :) and there is no XSS mitigation related to Script URLs (http://blogs.msdn.com/dross/archive/2008/03/10/xss-focused-attack-surface-reduction.aspx ) since they still work when exploiting XSS.
Alex was very kind to set up a PoC http://kuza55.awardspace.com/jsuri.html that's shows that you can still get script code executing by using Script URLs.
Thanks to David Ross comments pointing out scenarios were Script URLs are not executed.
Sep 7, 2008
Something that's gone, it's not "really" gone
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
<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
Subscribe to:
Posts (Atom)