X-FRAME-OPTIONS in Firefox
Posted by: Giorgio in Clickjacking, IE, Mozilla, Security, NoScriptAs I promised in my previous posts about so called IE8's "Clickjacking protection", some hours ago I released the NoScript 1.8.9.9 development build, featuring experimental but complete compatibility with the X-FRAME-OPTIONS header support introduced by IE8 and unveiled yesterday by Eric Lawrence on the IE Blog.
As I said previously,
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.
The following screenshot shows the original IE8 implementation as can be tested on my demo page:
And this is X-IFRAME-OPTIONS in action on Firefox (kindly provided by NoScript for now, but already in the works as a built-in):
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 :)
January 30th, 2009 at 5:55 am
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?
January 30th, 2009 at 7:00 am
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.
January 30th, 2009 at 11:39 am
@anonymous:
I know some people may get it just saying it once.
But I've got to target people like Larry Seltzer here at Security Watch, who unluckily are also opinion leaders.
Sorry for the inconvenience.
January 30th, 2009 at 11:35 pm
Bah; it does not bother me. But I'm an idiot, so... :-)
January 31st, 2009 at 7:12 pm
Larry Seltzer posted a rectification, honestly admitting he had been mislead about by the old original RSnake's Clickjacking details post (which, by the way, actually said that current -- three months ago -- NoScript versions did protect against Clickjacking, opposite to older versions which could be circumvented).
Anyway, thanks Larry, I did appreciate that, even though I couldn't post not even a simple "Thanks" as a comment on your blog, because of the unbelievable suckiness of PCMag's spam filters...
January 31st, 2009 at 11:07 pm
[...] 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 [...]
February 1st, 2009 at 2:16 pm
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.
Also, awesome extension
Gr. Joris
February 1st, 2009 at 9:13 pm
@Joris:
Fixed in 1.9.0.2, thanks.
Notice that you won't get an error message for OBJECT elements, but the request gets blocked anyway.
February 2nd, 2009 at 1:50 am
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)?
February 2nd, 2009 at 2:27 am
@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).
February 7th, 2009 at 7:02 pm
[...] send Roger an email, sparking a pretty intense exchange (in the meanwhile, I was implementing PoC X-Frame-Options compatibility for Firefox with my left [...]
March 13th, 2009 at 6:10 pm
[...] incident reporting tool. Improved script blocking and scriptless pages management. Improved X-FRAME-OPTIONS compatibility support. New exclusive protection against JSON and E4X hijacking. Anti-XSS filters performance [...]
October 30th, 2009 at 3:25 am
[...] useful discussion on the issue can also be found in this post on [...]
December 2nd, 2009 at 10:14 pm
[...] 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 [...]
January 27th, 2010 at 2:31 am
I've implemented X-Frame-Options on my website using some simple Apache config. See https://secure.grepular.com/ClickJacking_and_SSL_Protection_in_Apache for information on how to do it.