Properties set on an IFrame’s window object during its onunload event persisted after the IFrame navigated to a different origin. Setting onload in onunload was particularly convenient because the persisted handler fired automatically when the new cross-origin page finished loading, giving the attacker code that ran in the new context.
iFrame.SET_ANY_VARIABLE_FIRST_SO_THE_TRICK_WORKS = 1;
iFrame.onunload = function() {
iFrame.onload = iFrame.Function(
"alert('URL: ' + document.URL + '\\n\\n' + document.body.outerHTML)"
);
};
iFrame.location.replace("http://www.victim.com/");
The prerequisite was that the target page had at least one HTML element with an inline event handler before any <script> or <link> tag. Most pages with <link> tags in the header were less vulnerable, but the IE XSS filter could be used to neuter those <link> tags, expanding the attack surface. This variation was also explored by David Ross, who wrote about the underlying design question in his MSDN blog post “Fuzzing for Design Bugs?”.
Found during my years at Microsoft (2006–2014). These bugs were patched long ago — shared here as a historical record for learning purposes.