Question

This question was previously asked and answered correctly, but there did not seem to be a solution posted.

If a site has iframes, and one wants to prevent those from being enclosed in a frame from a different domain, simplistic frame-busting will not be useful:

<script>if (top != self) top.location = location</script>

However, since cross-frame scripting to other domains should generate exceptions, something like this seems to work well inside the iframe:

<script>
try {
  if (window.document.domain != top.document.domain) {   // throws exception
    throw "You naughty puppy!"; // Should not ever get here, right?
  }
}
catch () {
  top.location = "/error/naughtypuppy";
}
</script>

The if above should be enough on its own to prevent cross-domain framing of iframes. It should only ever return false or throw an exception, so is there anyway the script could reach the throw statement in a browser?

Would this be sufficient to prevent framing only from other domains?

<script>
try {
  var bogus = top.document.domain;
}
catch () {
  top.location = "/error/naughtypuppy";
}
</script>

Edit: A similar solution is hinted at here, but one would not rely on the parent frame to include the frame-busting code. Detect when iframe is cross-domain, then bust out of it . Essentially the same solution as “try to access the other frame and bust if an exception occurs.”

Answer 1

That code is vulnerable to a form of attack that leverages the “onbeforeunload” feature. The parent (evil) page sets up a interval handler (which is invulnerable to your code, due to the domain difference) and an “onbeforeunload” handler. The second handler just updates some global variable (also invulnerable) to record the fact that the window is “under attack”, and then the interval timer (running fast enough that it should be able to become active before the browser has completed the outer window update to your legit URL) pops up and updates window.location to point to some attacker-controlled URL that returns a no-op 204 response. The browser forgets about your HTTP request and “updates” the window from that newer transaction instigated by the interval handler instead.

Here’s the older SO question: Frame Buster Buster … buster code needed