this is just a cross-browser compatibility effort: neither Firefox nor NoScript really need this feature. Traditional JavaScript-based frame busting works fine in Firefox, giving it the same degree of (modest) "protection" as IE8. NoScript users, on the other hand, are already fully protected, because ClearClick is the one and only countermeasure which works against any type of Clickjacking (frame or embed based), no matter if web sites cooperate or not.

However I also said this is nice to have. I had already imagined a functionally similar declarative solution, the SUB pseudo-method of ABE rules, and HTTP-based restrictions can actually be easier to deploy in some scenarios (e.g. using a Web Application Firewall).

More important, not every IT manager will have a chance of reading the reasons I exposed so far, explaining why IE8 has no more "Clickjacking protection" than its competitors. Our typical decision maker will just read a bullet list including "Clickjacking protection", will find that no other browser dares such a claim and will base his choice (also) on that misleading comparison.

So let's add this bullet, even if it does nothing against Clickjacking that "alternative browsers" couldn't already do with traditional frame busting.

But now that we've got "bullet parity", let's put the marketspeak aside and keep enjoying the only Clickjacking protection that really works "out of the box": your friendly neighborhood ClearClick :)

This entry was posted on Thursday, January 29th, 2009 at 11:36 pm and is filed under Clickjacking, IE, Mozilla, Security, NoScript. You can follow any responses to this entry through the RSS 2.0 feed.
Both comments and pings are currently closed.

15 Responses to “X-FRAME-OPTIONS in Firefox”

Hey. There was an article today (on ZDNet I think) about clickjacking in all the browsers. Are there bugs for all the features you've put in NoScript? Maybe track them all with a metabug I could subscribe to?

Ohh for god's sake .. how many times will you tell "only protection that works out of the box"

we get it ... we are not idiots!!!

are you writing a blog targetting idiots - the way ads on television are ? we get it when you tell us once - this post could have just been - I added support in noScript check out the screenshots - everything else you have already said in previous posts.

[...] protection which will work on those pages whose authors decide to adopt the new proprietary X-FRAME-OPTIONS header (now cross-browser), interest of the press about this topic has been raising again. Unluckily, Clickjacking (or more [...]

Just did some tests and it appears that "X-IFRAME-OPTIONS" does not work with <object data="http://evil.hackademix.net/frameopts/?o=2"></object>.

Also, I have noticed that sometimes the link "Click here to open this content in a new window" will open the chrome url of the error message instead of the page. Unfortunately I am not sure how to properly recreate this.

I know it's a small issue, but this feature should allow the user to override it, so it isn't misused. Unfortunately, unlike JS frame busting, there is presently no practical means for the user to override this feature when it is abused by web publishers. For example, if a page doesn't want to be framed, not for security, but as part of yet another obnoxious, paranoid, and ineffective "copy-protection" scheme (like those "clever" scripts that set onselectstart, etc to function(){return false}), and I land on said page framed as a Google image search result, I can stop it from frame-busting by denying its JS. (Actually, can I -- or does NoScript prevent me from stopping it by emulating frame-busting without consulting the user?) Now, if the HTTP header is honoured without giving the user a means to override it, how then do I prevent the page messing up a legitimate framing (such as an images.google result, or a Facebook posted item)?

@MacOtaku:
"Traditional" frame busting emulation is controlled by the noscript.emulateFrameBreak about:config preference.
I can add a similar preference for X-FRAME-OPTIONS in next release (it was already planned, anyway).

[...] frame) — or a blank one if you’re on Chrome — because Google is sending down a X-Frame-Option HTTP header with value SAMEORIGIN, allowing only pages served from www.google.com to embed this [...]