开发者

Frame breaking only cross-domain but not for iframes from the same origin?

开发者 https://www.devze.com 2023-01-17 22:21 出处:网络
This question was previously asked and answered correctly, but there did not seem to be a solution posted.

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."


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


I have a site that still has frames and I can't remove them for now. This was the best solution I was able to find:

<style>html { display:none }</style>
<script>
if (self == top) {
  document.documentElement.style.display = 'block';
} else {
  top.location = self.location;
}
</script> 

From this link: XFS 101-cross-frame-scripting-explained

Based on a presentation from: OWASP_AppSec_Research_2010_Busting_Frame_Busting_by_Rydstedt

Here is a more updated OWasp Clickjacking page

0

精彩评论

暂无评论...
验证码 换一张
取 消