Frame Buster Buster ... buster code needed

G

20

438

Let's say you don't want other sites to "frame" your site in an <iframe>:

<iframe src="http://example.org"></iframe>

So you insert anti-framing, frame busting JavaScript into all your pages:

/* break us out of any containing iframes */
if (top != self) { top.location.replace(self.location.href); }

Excellent! Now you "bust" or break out of any containing iframe automatically. Except for one small problem.

As it turns out, your frame-busting code can be busted, as shown here:

<script type="text/javascript">
    var prevent_bust = 0  
    window.onbeforeunload = function() { prevent_bust++ }  
    setInterval(function() {  
      if (prevent_bust > 0) {  
        prevent_bust -= 2  
        window.top.location = 'http://example.org/page-which-responds-with-204'  
      }  
    }, 1)  
</script>

This code does the following:

increments a counter every time the browser attempts to navigate away from the current page, via the window.onbeforeunload event handler
sets up a timer that fires every millisecond via setInterval(), and if it sees the counter incremented, changes the current location to a server of the attacker's control
that server serves up a page with HTTP status code 204, which does not cause the browser to navigate anywhere

My question is -- and this is more of a JavaScript puzzle than an actual problem -- how can you defeat the frame-busting buster?

I had a few thoughts, but nothing worked in my testing:

attempting to clear the onbeforeunload event via onbeforeunload = null had no effect
adding an alert() stopped the process let the user know it was happening, but did not interfere with the code in any way; clicking OK lets the busting continue as normal
I can't think of any way to clear the setInterval() timer

I'm not much of a JavaScript programmer, so here's my challenge to you: hey buster, can you bust the frame-busting buster?

Gifford answered 6/6, 2009 at 4:29 Comment(25)

I don't have the means to test this at the moment, but it seems like the only way to block the very fast timer in the top page is to actively block the single javascript thread the browser has with an infinite loop. What I don't know is if the brower will be able to reload the top page while this is going on. top.location.replace(self.location.href); while(true) { } – Hellenistic 6/6, 2009 at 4:45

I'm not sure the frame-buster-buster actually works...when I try to test it (redirecting to a handler I set up to return a 204), it prevents me from navigating anywhere outside the page--including typing stuff in the address bar! I have to close down the browser tab and open a new one in order to get anywhere. So in other words, I'm not sure this needs a solution, because the frame-buster-buster wanting to be busted is...busted to start with. :) (Either that or I screwed up my test, which could never happen...) ;) – Paedogenesis 6/6, 2009 at 5:4

Matt, the frame-buster-buster code posted above definitely works. A.. uh.. friend.. of mine.. told me .. about it. Or something. :) – Gifford 6/6, 2009 at 5:7

... like using <body onbeforeunload="prevent_bust++"> instead of window.onbeforeunload or something like that ;] – Hypnotize 6/6, 2009 at 5:22

well, I say to that .. top.document.body.onbeforeunload = null; :) – Gifford 6/6, 2009 at 6:49

Jeff, are you testing with both windows on the same domain? It looks like you are because if you weren't then security restrictions would prevent you from modifying 'onBeforeUnload' – Vilma 6/6, 2009 at 8:23

On a side note: When posting examples, please use domains like example.org as specified in RFC 2606 ietf.org/rfc/rfc2606.txt – Bait 6/6, 2009 at 9:49

@Matt Winckler - I agree. The buster-buster code seems very unreliable. Testing on Firefox 2 and 3, I got the same behaviour as you. In IE6,7,8, Safari 3, Opera 9.6, Chrome 2 it had no effect. – Tunesmith 6/6, 2009 at 11:47

@Steve Reed - while(true) just freezes the page, but using that idea, adding a short pause there works. By the time the interval code gets access to the thread, it's too late, and the contained page has busted out. – Tunesmith 7/6, 2009 at 11:52

I just updated my answer, please give it a try. – Blowtorch 18/6, 2009 at 16:8

Just out of curiosity, why would you want to do this? This sounds like it was invented by the people who wanted to stop everyone from right clicking on their page... – Pfaff 18/6, 2009 at 16:19

youtube.com/watch?v=Iw3G80bplTg For those who don't get the reference. NSFW profanity – Obedient 19/6, 2009 at 4:54

If you want to test your buster buster buster, I made a page that frames any given URL. – Edra 10/11, 2009 at 20:12

Regarding the general theme of counter-counter-countermeasures: galactanet.com/comic/view.php?strip=209 – Harmsworth 23/11, 2009 at 14:20

This guy has a question about your frame buster: #2298939 . Jeff or someone should help out this guy. – Flaring 19/2, 2010 at 18:21

Jeff, stackoverflow's frame-buster-buster-buster isn't working in Chrome 10.0.634.0 dev on Windows XP SP3. After clicking "OK" the page is blank (all white) and the iframe src is reported as stackoverflow.com. The src of the iframe is set dynamically. – Lowrie 20/1, 2011 at 18:22

@david we don't support beta browsers.. period. – Gifford 20/1, 2011 at 19:50

psh, this isn't a beta! Its cutting edge! haha. I just figured you'd like to know as the frame-bustin` will probably not work in a couple weeks/months when the stable channel catches up. – Lowrie 20/1, 2011 at 22:21

Related X-Frame-Options Mozilla spec browser support to avoid clickjacking etc. – Censorious 7/10, 2011 at 15:40

Matt, for what it's worth, if using JQuery, you can re-enable all the links on your page after implementing the framebuster-buster with something like $("a").click(function() { prevent_bust--; }); at the bottom of the page – Elburr 20/8, 2012 at 18:4

@MattWinckler, I replicated your problem of not being able to click on anything. What I did was clear the interval after the first "onbeforeunload" to kick in. Since the frame will be the very first one to trigger that, succeeding events (such as link click) won't be blocked anymore. Code:

var prevent_bust = 0 window.onbeforeunload = function() { prevent_bust++ } var interval = setInterval(function() { if (prevent_bust > 0) { prevent_bust -= 2; window.top.location = 'example.org/204.php'; clearInterval(interval); } }, 1);

– Yahiya 18/3, 2013 at 0:56

A couple iterations later, and we'll be seeing a frame buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster buster – Pontefract 6/7, 2014 at 0:52

Does the above frame busting..buster code work today in modern browsers? It doesn't appear to work for me against: <script>if(top != self) top.location.href = location.href;</script> Also, where do we find a server that returns 204? – Lipscomb 4/2, 2017 at 15:49

CSP is the way to go these days, per this Answer: https://mcmap.net/q/80596/-frame-buster-buster-buster-code-needed . Note that a determined abuser can simply pull your page and reproduce it themselves from the back end, so there's no way to absolutely prevent somebody from duplicating your content on their site. – Saveloy 3/12, 2019 at 16:48

that busting frame-busting code sample is non deterministic, it depends on who won the race condition of onbeforeunload and setInterval, also sometimes I cannot type/click anything, this may be for the setInterval waking up every 1 ms – Tithable 19/2, 2021 at 4:32

M

150

I'm not sure if this is viable or not - but if you can't break the frame, why not just display a warning. For example, If your page isn't the "top page" create a setInterval method that tries to break the frame. If after 3 or 4 tries your page still isn't the top page - create a div element that covers the whole page (modal box) with a message and a link like...

You are viewing this page in a unauthorized frame window - (Blah blah... potential security issue)

click this link to fix this problem

Not the best, but I don't see any way they could script their way out of that.

Machinate answered 18/6, 2009 at 13:21 Comment(6)

I have tried this and this works. Another piece that I like about this solution is that it brings to light to the user what kind of site he/she was on before going to your content. Sample Code: if (parent.frames.length > 0) { top.location.replace(document.location); setTimeout(function() { if (parent.frames.length > 0) { document.location = "google.com"; } }, 10); } – Semibreve 21/6, 2009 at 2:55

Not only is this a good way of avoiding abuse, it's pretty friendly to sites who may want to iframe your site just to take a peek at it, though not to allow use of it. Ideally, I think a screenshot of the site's homepage should be used, with some explanation of why it can't be used in the iframe overlaid on top. – Willey 11/2, 2010 at 18:19

This is how Facebook does it. – Idem 24/1, 2011 at 7:34

but maybe this could be exploited if the busting site in turn will create a false anti anti anti ... (dunno how much anti we are up to now) lighbox div for itself presenting a phishing link or whatever ... tbc – Kuhlman 1/10, 2011 at 15:12

Another idea would be to just wipeout the page completely with something like document.write(""); (after you have established that it is being framed – Ketti 24/6, 2012 at 4:42

Keep in mind that a proxy can always be used to defeat any frame-buster. This is used by sites like Optimizely in their WYSIWYG editors. You'll see that instead of <iframe src="http://yoursite.com"> they use <iframe src="http://proxy.com?url=http://yoursite.com"> and this yields the same visual result and (AFAIK) cannot be defeated as it's indistinguishable from a legitimate visitor. – Crud 19/11, 2014 at 22:41

S

211

FWIW, most current browsers support the X-Frame-Options: deny directive, which works even when script is disabled.

IE8:
http://blogs.msdn.com/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx

Firefox (3.6.9)
https://bugzilla.mozilla.org/show_bug.cgi?id=475530
https://developer.mozilla.org/en/The_X-FRAME-OPTIONS_response_header

Chrome/Webkit
http://blog.chromium.org/2010/01/security-in-depth-new-security-features.html
http://trac.webkit.org/changeset/42333

Signally answered 19/3, 2010 at 18:54 Comment(10)

excellent, supporting this in the browser .exe is the way to go without a doubt. When you say "most browsers", which ones specifically? I can't find good sources for anything but IE8. – Gifford 29/3, 2010 at 21:50

Here's a test page: enhanceie.com/test/clickjack. Chrome 4.1.249.1042 supports. Opera 10.50 supports. Firefox 3.6.2 does NOT yet support. Safari 4.0.3 supports. – Signally 30/3, 2010 at 19:27

Firefox 3.6.9 will support it natively ( hackademix.net/2010/08/31/… ) and any Firefox install with NoScript has had it since the beginning of 2009 ( hackademix.net/2009/01/29/x-frame-options-in-firefox ) – Velours 31/8, 2010 at 5:47

@JeffAtwood The latest versions of Chrome, FF, IE, Opera, Safari all support it. – Stickseed 3/7, 2012 at 14:58

It's best to combine this with the javascript framebuster. – Goethite 28/12, 2012 at 23:40

Or combine this with the December '12 answer on this page: https://mcmap.net/q/80596/-frame-buster-buster-buster-code-needed – Censorious 28/3, 2013 at 18:44

X-Frame-Options are HTTP Headers not HTML Headers so it makes sense they work even with no-script on. – Roca 27/8, 2013 at 10:48

@Pogrindis: ssokolow's point was that, prior to the introduction of native support in Firefox 3.6.9, you could get support for X-Frame-Options by having the NoScript addon installed. – Signally 27/8, 2013 at 17:35

@Signally i missed that! Fair enough! – Roca 28/8, 2013 at 8:54

Looks like this is the approach now in use on stackoverflow – Enciso 29/8, 2013 at 11:11

M

150

I'm not sure if this is viable or not - but if you can't break the frame, why not just display a warning. For example, If your page isn't the "top page" create a setInterval method that tries to break the frame. If after 3 or 4 tries your page still isn't the top page - create a div element that covers the whole page (modal box) with a message and a link like...

You are viewing this page in a unauthorized frame window - (Blah blah... potential security issue)

click this link to fix this problem

Not the best, but I don't see any way they could script their way out of that.

Machinate answered 18/6, 2009 at 13:21 Comment(6)

I have tried this and this works. Another piece that I like about this solution is that it brings to light to the user what kind of site he/she was on before going to your content. Sample Code: if (parent.frames.length > 0) { top.location.replace(document.location); setTimeout(function() { if (parent.frames.length > 0) { document.location = "google.com"; } }, 10); } – Semibreve 21/6, 2009 at 2:55

Not only is this a good way of avoiding abuse, it's pretty friendly to sites who may want to iframe your site just to take a peek at it, though not to allow use of it. Ideally, I think a screenshot of the site's homepage should be used, with some explanation of why it can't be used in the iframe overlaid on top. – Willey 11/2, 2010 at 18:19

This is how Facebook does it. – Idem 24/1, 2011 at 7:34

but maybe this could be exploited if the busting site in turn will create a false anti anti anti ... (dunno how much anti we are up to now) lighbox div for itself presenting a phishing link or whatever ... tbc – Kuhlman 1/10, 2011 at 15:12

Another idea would be to just wipeout the page completely with something like document.write(""); (after you have established that it is being framed – Ketti 24/6, 2012 at 4:42

Keep in mind that a proxy can always be used to defeat any frame-buster. This is used by sites like Optimizely in their WYSIWYG editors. You'll see that instead of <iframe src="http://yoursite.com"> they use <iframe src="http://proxy.com?url=http://yoursite.com"> and this yields the same visual result and (AFAIK) cannot be defeated as it's indistinguishable from a legitimate visitor. – Crud 19/11, 2014 at 22:41

V

38

We have used the following approach in one of our websites from http://seclab.stanford.edu/websec/framebusting/framebust.pdf

<style>
 body { 
 display : none   
}
</style>
<script>
if(self == top) {
document.getElementsByTagName("body")[0].style.display = 'block';
}
else{
top.location = self.location;
}
</script>

Vitalize answered 4/12, 2012 at 17:26 Comment(6)

Bingo! Not sure why this isn't upvoted more since it is the best answer(next to the X-Frame-Options answer, but it's best to combine both) – Goethite 28/12, 2012 at 23:49

This answer or mine should be selected :) – Inbreeding 2/9, 2013 at 12:12

I like your idea of using both this and the X-Frame-Options:deny answer. – Hest 5/6, 2014 at 16:36

This requires JS, which is a pretty big burden IMHO. – Navicular 2/9, 2015 at 8:3

+1 - This is the best answer when X-FRAME-OPTIONS can't be used. (For example, when you need to conditionally allow or deny depending on referrer.) – Otoplasty 9/8, 2017 at 14:17

@Navicular This requires JS for legitimate users. Disabling JS will not make user vulnerable to frame-buster buster, at least. – Soma 13/8, 2018 at 16:18

D

29

Came up with this, and it seems to work at least in Firefox and the Opera browser.

if(top != self) {
 top.onbeforeunload = function() {};
 top.location.replace(self.location.href);
}

Developing answered 6/6, 2009 at 4:55 Comment(7)

both Jani and Jeff's solution (once edited) are correct and work equivalently; giving Jani the accept because his solution worked right without any editing – Gifford 6/6, 2009 at 4:59

This will only work if the two windows are of the same domain; a rare occurrence when you want to escape from a frame. – Vilma 6/6, 2009 at 8:17

If there are nested frames involved, you'll have to walk the frame chain and remove all onbeforeunload handlers, not just the one on top! – Bait 6/6, 2009 at 9:1

important clarification: this worked for me because the iframe src= was being set dynamically, and thus the cross-domain policy was NOT in effect. J-P is absolutely right, in a static src= this wouldn't work. – Gifford 7/6, 2009 at 9:17

ok now can someone come up with a frame buster buster buster buster? – Mccammon 12/6, 2009 at 14:45

Jeff, are you trying to say that setting the SRC to a different domain programmatically bypasses the cross-domain policy? If so, that seems like a ridiculous bug that you certainly should not rely on. – Blowtorch 18/6, 2009 at 17:11

Additionally, if that is true, all the evil site has to do to counteract this is set the SRC on the server-side instead...? – Blowtorch 18/6, 2009 at 17:12

I

27

Considering current HTML5 standard that introduced sandbox for iframe, all frame busting codes that provided in this page can be disabled when attacker uses sandbox because it restricts the iframe from following:

allow-forms: Allow form submissions.
allow-popups: Allow opening popup windows.
allow-pointer-lock: Allow access to pointer movement and pointer lock.
allow-same-origin: Allow access to DOM objects when the iframe loaded form same origin
allow-scripts: Allow executing scripts inside iframe
allow-top-navigation: Allow navigation to top level window

Please see: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox

Now, consider attacker used the following code to host your site in iframe:

<iframe src="URI" sandbox></iframe>

Then, all JavaScript frame busting code will fail.

After checking all frame busing code, only this defense works in all cases:

<style id="antiClickjack">body{display:none !important;}</style>
<script type="text/javascript">
   if (self === top) {
       var antiClickjack = document.getElementById("antiClickjack");
       antiClickjack.parentNode.removeChild(antiClickjack);
   } else {
       top.location = self.location;
   }
</script>

that originally proposed by Gustav Rydstedt, Elie Bursztein, Dan Boneh, and Collin Jackson (2010)

Inbreeding answered 16/5, 2013 at 20:53 Comment(0)

B

20

After pondering this for a little while, I believe this will show them who's boss...

if(top != self) {
  window.open(location.href, '_top');
}

Using _top as the target parameter for window.open() will launch it in the same window.

Blowtorch answered 18/6, 2009 at 14:40 Comment(0)

P

11

As of 2015, you should use CSP2's frame-ancestors directive for this. This is implemented via an HTTP response header.

e.g.

Content-Security-Policy: frame-ancestors 'none'

Of course, not many browsers support CSP2 yet so it is wise to include the old X-Frame-Options header:

X-Frame-Options: DENY

I would advise to include both anyway, otherwise your site would continue to be vulnerable to Clickjacking attacks in old browsers, and of course you would get undesirable framing even without malicious intent. Most browsers do update automatically these days, however you still tend to get corporate users being stuck on old versions of Internet Explorer for legacy application compatibility reasons.

Peony answered 8/7, 2015 at 9:1 Comment(1)

All major browsers now support CSP. This is the correct answer in 2019 and the forseeable future. – Saveloy 3/12, 2019 at 16:45

D

6

All the proposed solutions directly force a change in the location of the top window. What if a user wants the frame to be there? For example the top frame in the image results of search engines.

I wrote a prototype where by default all inputs (links, forms and input elements) are disabled and/or do nothing when activated.

If a containing frame is detected, the inputs are left disabled and a warning message is shown at the top of the page. The warning message contains a link that will open a safe version of the page in a new window. This prevents the page from being used for clickjacking, while still allowing the user to view the contents in other situations.

If no containing frame is detected, the inputs are enabled.

Here is the code. You need to set the standard HTML attributes to safe values and add additonal attributes that contain the actual values. It probably is incomplete and for full safety additional attributes (I am thinking about event handlers) will probably have to be treated in the same way:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
  <head>
    <title></title>
    <script><!--
      function replaceAttributeValuesWithActualOnes( array, attributeName, actualValueAttributeName, additionalProcessor ) {
        for ( var elementIndex = 0; elementIndex < array.length; elementIndex += 1 ) {
          var element = array[ elementIndex ];
          var actualValue = element.getAttribute( actualValueAttributeName );
          if ( actualValue != null ) {
            element[ attributeName ] = actualValue;
          }

          if ( additionalProcessor != null ) {
            additionalProcessor( element );
          }
        }
      }

      function detectFraming() {
        if ( top != self ) {
          document.getElementById( "framingWarning" ).style.display = "block";
        } else {
          replaceAttributeValuesWithActualOnes( document.links, "href", "acme:href" );

          replaceAttributeValuesWithActualOnes( document.forms, "action", "acme:action", function ( form ) {
            replaceAttributeValuesWithActualOnes( form.elements, "disabled", "acme:disabled" );
          });
        }
      }
      // -->
    </script>
  </head>
  <body onload="detectFraming()">
    <div id="framingWarning" style="display: none; border-style: solid; border-width: 4px; border-color: #F00; padding: 6px; background-color: #FFF; color: #F00;">
      <div>
        <b>SECURITY WARNING</b>: Acme App is displayed inside another page.
        To make sure your data is safe this page has been disabled.<br>
        <a href="framing-detection.html" target="_blank" style="color: #090">Continue working safely in a new tab/window</a>
      </div>
    </div>
    <p>
      Content. <a href="#" acme:href="javascript:window.alert( 'Action performed' );">Do something</a>
    </p>
    <form name="acmeForm" action="#" acme:action="real-action.html">
      <p>Name: <input type="text" name="name" value="" disabled="disabled" acme:disabled=""></p>
      <p><input type="submit" name="save" value="Save" disabled="disabled" acme:disabled=""></p>
    </form>
  </body>
</html>

Directive answered 19/6, 2009 at 1:47 Comment(3)

The problem with this is the frame-maker could use position:absolute to place active button on top of your inactive buttons and the user will just see your webpage and think they are clicking YOUR buttons. – Buckling 21/6, 2009 at 8:36

The warning message would still be shown, but of course it is easy to cover the link to the safe page as you suggest. But why go through all the trouble of framing my page to get people to click on a familiar button if you can simply copy the page and achieve the same effect? The code above mainly prevents clickjacking. If you show my page invisibly above another page it isn't possible to invoke actions on my site. – Directive 23/6, 2009 at 12:21

If this is placed in an IE8 restricted zone frame or Chrome sandbox frame the Javascript will never run. I wonder what modifications are needed in those cases – Censorious 28/3, 2013 at 18:49

H

6

if (top != self) {
  top.location.replace(location);
  location.replace("about:blank"); // want me framed? no way!
}

Handedness answered 19/6, 2009 at 15:23 Comment(0)

I

6

I'm going to be brave and throw my hat into the ring on this one (ancient as it is), see how many downvotes I can collect.

Here is my attempt, which does seem to work everywhere I have tested it (Chrome20, IE8 and FF14):

(function() {
    if (top == self) {
        return;
    }

    setInterval(function() {
        top.location.replace(document.location);
        setTimeout(function() {
            var xhr = new XMLHttpRequest();
            xhr.open(
                'get',
                'http://mysite.tld/page-that-takes-a-while-to-load',
                false
            );
            xhr.send(null);
        }, 0);
    }, 1);
}());

I placed this code in the <head> and called it from the end of the <body> to ensure my page is rendered before it starts arguing with the malicious code, don't know if this is the best approach, YMMV.

How does it work?

...I hear you ask - well the honest answer is, I don't really know. It took a lot of fudging about to make it work everywhere I was testing, and the exact effect that it has varies slightly depending on where you run it.

Here is the thinking behind it:

Set a function to run at the lowest possible interval. The basic concept behind any of the realistic solutions I have seen is to fill up the scheduler with more events than the frame buster-buster has.
Every time the function fires, try and change the location of the top frame. Fairly obvious requirement.
Also schedule a function to run immediately which will take a long time to complete (thereby blocking the frame buster-buster from interfering with the location change). I chose a synchronous XMLHttpRequest because it's the only mechanism I can think of that doesn't require (or at least ask for) user interaction and doesn't chew up the user's CPU time.

For my http://mysite.tld/page-that-takes-a-while-to-load (the target of the XHR) I used a PHP script that looks like this:

<?php sleep(5);

What happens?

Chrome and Firefox wait the 5 seconds while the XHR completes, then successfully redirect to the framed page's URL.
IE redirects pretty much immediately

Can't you avoid the wait time in Chrome and Firefox?

Apparently not. At first I pointed the XHR to a URL that would return a 404 - this didn't work in Firefox. Then I tried the sleep(5); approach that I eventually landed on for this answer, then I started playing around with the sleep length in various ways. I could find no real pattern to the behaviour, but I did find that if it is too short, specifically Firefox will not play ball (Chrome and IE seem to be fairly well behaved). I don't know what the definition of "too short" is in real terms, but 5 seconds seems to work every time.

If any passing Javascript ninjas want to explain a little better what's going on, why this is (probably) wrong, unreliable, the worst code they've ever seen etc I'll happily listen.

Indication answered 15/8, 2012 at 15:38 Comment(1)

Seems you can remove all your worrying sentences – Dejected 29/3, 2018 at 9:49

N

5

Ok, so we know that were in a frame. So we location.href to another special page with the path as a GET variable. We now explain to the user what is going on and provide a link with a target="_TOP" option. It's simple and would probably work (haven't tested it), but it requires some user interaction. Maybe you could point out the offending site to the user and make a hall of shame of click jackers to your site somewhere.. Just an idea, but it night work..

Nealon answered 12/6, 2009 at 1:44 Comment(0)

G

4

Well, you can modify the value of the counter, but that is obviously a brittle solution. You can load your content via AJAX after you have determined the site is not within a frame - also not a great solution, but it hopefully avoids firing the on beforeunload event (I am assuming).

Edit: Another idea. If you detect you are in a frame, ask the user to disable javascript, before clicking on a link that takes you to the desired URL (passing a querystring that lets your page know to tell the user that they can re-enable javascript once they are there).

Edit 2: Go nuclear - if you detect you are in a frame, just delete your document body content and print some nasty message.

Edit 3: Can you enumerate the top document and set all functions to null (even anonymous ones)?

Gravimetric answered 6/6, 2009 at 4:40 Comment(1)

Outlook (formerly Hotmail) 'goes nuclear' if it can't get out of a frame - it puts the the entire content of the <body> inside a <plaintext> tag set to display: none. It's quite effective. – Uncrowned 31/10, 2012 at 20:6

H

4

If you add an alert right after the buster code, then the alert will stall the javascript thread, and it will let the page load. This is what StackOverflow does, and it busts out of my iframes, even when I use the frame busting buster. It also worked with my simple test page. This has only been tested in Firefox 3.5 and IE7 on windows.

Code:

<script type="text/javascript">
if (top != self){
  top.location.replace(self.location.href);
  alert("for security reasons bla bla bla");
}
</script>

Helgoland answered 22/7, 2009 at 9:17 Comment(0)

R

3

I think you were almost there. Have you tried:

window.parent.onbeforeunload = null;
window.parent.location.replace(self.location.href);

or, alternatively:

window.parent.prevent_bust = 0;

Note: I didn't actually test this.

Rad answered 6/6, 2009 at 4:48 Comment(3)

I edited your code sample (the test for parent seems to fail) but the edited version DOES appear to work! – Gifford 6/6, 2009 at 4:57

Cool. It's always tricky to answer with untested code - I do it to at least get the idea across - and let the poor asker debug. :) – Rad 6/6, 2009 at 5:0

Won't work if parent is on a different domain, which is likely the case! – Blowtorch 18/6, 2009 at 14:41

B

3

If you look at the values returned by setInterval() they are usually single digits, so you can usually disable all such interrupts with a single line of code:

for (var j = 0 ; j < 256 ; ++j) clearInterval(j)

Boiardo answered 21/2, 2010 at 8:57 Comment(0)

B

2

What about calling the buster repeatedly as well? This'll create a race condition, but one may hope that the buster comes out on top:

(function() {
    if(top !== self) {
        top.location.href = self.location.href;
        setTimeout(arguments.callee, 0);
    }
})();

Bait answered 6/6, 2009 at 9:20 Comment(0)

D

2

I might just have just gotten a way to bust the frame buster buster javascript. Using the getElementsByName in my javascript function, i've set a loop between the frame buster and the actual frame buster buster script. check this post out. http://www.phcityonweb.com/frame-buster-buster-buster-2426

Drysalt answered 20/2, 2011 at 14:42 Comment(0)

S

0

setInterval and setTimeout create an automatically incrementing interval. Each time setTimeout or setInterval is called, this number goes up by one, so that if you call setTimeout, you'll get the current, highest value.

   var currentInterval = 10000;
   currentInterval += setTimeout( gotoHREF, 100 );
   for( var i = 0; i < currentInterval; i++ ) top.clearInterval( i );
   // Include setTimeout to avoid recursive functions.
   for( i = 0; i < currentInterval; i++ )     top.clearTimeout( i );

   function gotoHREF(){
           top.location.href = "http://your.url.here";
   }

Since it is almost unheard of for there to be 10000 simultaneous setIntervals and setTimeouts working, and since setTimeout returns "last interval or timeout created + 1", and since top.clearInterval is still accessible, this will defeat the black-hat attacks to frame websites which are described above.

Stenograph answered 23/12, 2009 at 15:40 Comment(0)

W

0

Use htaccess to avoid high-jacking frameset, iframe and any content like images.

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^http://www\.yoursite\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule ^(.*)$ /copyrights.html [L]

This will show a copyright page instead of the expected.

Wartime answered 18/12, 2013 at 19:14 Comment(1)

This relies on the referrer which is a) not always set (due to browser settings or extensions or simply because the referring page is using HTTPS without using <meta name="referrer" …/> and b) also set when clicking on links, so you also disallow links to your page and break the web. – Dichromaticism 7/7, 2017 at 7:49

M

0

You could improve the whole idea by using the postMessage() method to allow some domains to access and display your content while blocking all the others. First, the container-parent must introduce itself by posting a message to the contentWindow of the iframe that is trying to display your page. And your page must be ready to accept messages,

window.addEventListener("message", receiveMessage, false);

function receiveMessage(event) {
  // Use event.origin here like
  if(event.origin == "https://perhapsyoucantrustthisdomain.com"){
  // code here to block/unblock access ... a method like the one in user1646111's post can be good.
  }
  else{
  // code here to block/unblock access ... a method like the one in user1646111's post can be good.
  }
}

Finally don't forget to wrap things inside functions that will wait for load events.

Marshland answered 25/8, 2020 at 11:22 Comment(0)

Recommended topics

Hot tags