Modern-Day Frame Busting With X-FRAME-OPTIONS And "This content cannot be displayed in a frame" Warnings

Artem Russakovskii — Fri, 30 Oct 2009 01:10:32 +0000

Today I found out something entirely new about framebusting and specifically clickjacking protection techniques.

I was working with a site that was using frames. Suddenly, one of the frames (which was hosted on a domain that differed from the one it was embedded in) displayed the following message (in Firefox 3.5.4):

This content cannot be displayed in a frame
 
To protect your security, the publisher of this content does
not allow it to be displayed in a frame.
 
Click here to open this content in a new window

Notice how this is a native Firefox window and not a web page rendering. Quite stumped, I started looking at the frame response and finally found that it included this little header:

X-FRAME-OPTIONS: DENY

Turns out that modern browsers like ~~Firefox 3.5~~ (turns out it's the NoScript addon that does this and not Firefox itself) and IE8 treat this header as a precautionary measure and display a generic "warning" to the user instead of the page content in certain conditions described below. This effort, led, surprisingly, by Microsoft, was really to protect users from clickjacking (I wrote about clickjacking here earlier) but can be viewed as an alternative to framebusting.

Microsoft introduced the new X-FRAME-OPTIONS header with the following possible values:

DENY – prevents the page from being rendered if it is contained in a frame
SAMEORIGIN – same as above, unless the page belongs to the same domain as the top-level frameset holder.

~~Firefox adopted this technique a few months later~~ (again, I was wrong here – it was NoScript that did it), and I expect other browsers to follow.

So what does it mean to you, the developer?

setting such a header will essentially render frame busting code unnecessary in modern browsers
but it has a downside of displaying a relatively ugly warning to the user
no automatic redirect is done as your page (including any framebusting code) is not loaded
thus requiring an extra click
and popping up a new tab or window
it will work even if the user has Javascript disabled, which is more secure

Some useful discussion on the issue can also be found in this post on Hackademix.net.

So is it good practice to use this new X-FRAME-OPTIONS header instead of the traditional framebusting code? I definitely think so, especially if Firefox and other browsers start supporting it. What do you say?

How To Fight Clickjacking (Using The Recent Twitter Hijacking As An Example)

Artem Russakovskii — Thu, 12 Feb 2009 19:43:53 +0000

Introduction

Clickjacking is a malicious technique of tricking web users into revealing confidential information or taking control of their computer while clicking on seemingly innocuous web pages. A vulnerability across a variety of browsers and platforms, a clickjacking takes the form of embedded code or script that can execute without the user's knowledge, such as clicking on a button that appears to perform another function (credit: Wikipedia).

Clickjacking is hard to combat. From a technical standpoint, the attack is executed using a combination of CSS and iFrames, which are both harmless web technologies, and relies mostly on tricking users by means of social engineering. Additionally, the only server side technique against clickjacking known to me is “frame breaking”, which would cause a legitemate site to break out of any iFrames it may be embedded in. This is not always the desired behavior and is generally frowned upon.

XSS and CSRF are examples of similar malicious web attacks.

Generic Example

In laymen’s terms, clickjacking means that it is quite possible for websites to trick you into, for example, clicking a button to show a cute kitty while in reality prompting a deletion of all your hotmail email. A malicious site uses an iFrame (which essentially allows embedding sites within other sites) with hotmail loaded inside and hidden using CSS (which is a web language for styling HTML elements). A button named “Show Me The Next Awwww Kitty” is then placed by the malicious site and positioned below the iFrame layer (manipulated by CSS, yet again). However, because the iFrame is hidden, it looks like the “Aww” button is all you’re clicking. Wrong!

Latest Example: Twitter

This morning a new, though harmless, epidemic hit twitter. Hundreds and thousands of messages saying “Don’t Click: http://tinyurl.com/amgzs6” started showing up. Clicking the link shows a simple page with 1 button:

Clicking (which I of course did) uses clickjacking to repost the message to your own twitter account. Take a look yourself: http://search.twitter.com/search?q=don%27t+click.

All of these are a result of an experiment by some French guys to mess around with twitter and show the effects of clickjacking. Thank you for that, French guys. Creating awareness via the most social platform on the web is the best thing they could do for us.

Twitter rolled out a quick fix, using the very “frame breaking” technique I mentioned earlier. Now any site trying to embed twitter in an iFrame will redirect to it.

Fight Clickjacking

James Padolsey recently wrote an excellent blog post about clickjacking and mentioned Twitter specifically. Because clickjacking relies mostly on social hacking (i.e. tricking people into clicking malicious links and buttons), Twitter is nothing but a perfect platform. James gives some nice background info and code examples. He correctly highlights, as I did earlier, that clickjacking is not a software bug – it’s a malicious technique exploiting harmless technologies.

So how does one fight clickjacking?

At this point the most reliable way is to use Firefox and the NoScript extension. NoScript provides a simple, yet amazingly effective feature, called ClearClick. From their site:

“…it's enabled by default, protecting NoScript users from Clickjacking everywhere: it even remains active if you switch NoScript in the less safe Allow scripts globally mode. How does it work? Clickjacking hides or displaces or partially covers something you wouldn't want to click, if you could see it in its original context. ClearClick does the opposite: whenever you click a plugin object or a framed page, it takes a screenshot of it alone and opaque (i.e. an image of it with no transparencies and no overlaying objects), then compares it with a screenshot of the parent page as you can see it. If the two images differ, a clickjacking attack is probably happening and NoScript raises a "ClearClick warning", showing you the contextualized and "clear" object you were about to click, so you can evaluate by yourself if that was really something you wanted to do.”

Did ClearClick work in the earlier twitter attack? Sure did! After I clicked the “Don’t click” button Noscript promptly popped up a warning showing the hidden iFrame (since the original malicious page has been removed, I found another similar page from the same author for screenshot purposes).

So, even if you don’t want to enable NoScript globally, install it anyway, just for ClearClick.

Using a browser other than Firefox? The best technique you should use is, as a general rule, don’t click on suspicious buttons and links on pages you are not familiar with. Remember: you’re on the Internet and it is full of traps.

That about covers what I had to say about clickjacking. Stay safe, folks!