Monday, May 24th, 2010

Busting framebusters – clickjacking is still a big issue

Category: JavaScript, Security

If you followed the security world a bit in the last year (or fell for the “don’t click this button” Twitter worm) you will have noticed that clickjacking still is a big problem. Clickjacking basically means that you embed a third party web site into yours inside an iframe and give this frame a opacity of 0. That way the end users really interact with the third party web site instead of yours and unknowingly do things they didn’t intend to do.

Generally the most proposed way around clickjacking is to use framebusting code – which is a JavaScript that checks if the current document is the topmost document in the browser frames hierarchy and if it isn’t redirects to the real page:


  1. if(top.location != location){
  2.  top.location = self.location;
  3. }

The first problem with that is that it relies on JavaScript – which could be turned off or deliberately clobbered to stop working.

Where it gets really scary though is to see just how many workarounds for breaking framebusting scripts there are. The Stanford/Carnegie Mellon paper written by Gustav Rydstedt, Elie Bursztein, Dan Boneh, and Collin Jackson released at W2SP 2010 lists the following ones:

  • Double framing
  • onBeforeUnload – 204 Flushing
  • using onBeforeUnload for phishing
  • Exploiting the XSS Filter
  • Referrer checking problems
  • Clobbering top.location
  • IE Restricted Zone
  • Sandbox attribute
  • Design mode
  • Mobile Sites

You can download the paper for yourself to learn about these techniques – most of them relying on browser specific features and shortcomings.

Posted by Chris Heilmann at 5:38 am

3 rating from 1 votes


Comments feed TrackBack URI

I’m sorry to have to be this much of a nitpicker, but surely you mean opacity of 0% or 100% transparent.

Comment by SubtleGradient — May 24, 2010

I would suggest the main problem with this is it breaks legitimate uses for frames. And yes there are some.

Comment by ipearx — May 24, 2010

I could tell there was an iframe, because I have this in my Firefox’s userContent.css file to differentiate between page and iframes. I had it there to help debug stuff.
iframe:hover {outline:2px dotted red}

Comment by Jordan1 — May 24, 2010

I haven’t been able to break this little piece of code;
(function( top ){ while( top !== ){ top =; } if (top !== self) top.location.replace( self.location.href ); })( this );

With any of the techniques they suggest above ;)

Comment by V1 — May 26, 2010

Leave a comment

You must be logged in to post a comment.