Birth of a Security Feature: ClickJacking Defense

Anith » Birth of a Security Feature: ClickJacking Defense

Anith » Birth of a Security Feature: ClickJacking Defense — Tue, 03 Feb 2009 04:29:41 GMT

PingBack from http://www.anith.com/?p=4752

re: Birth of a Security Feature: ClickJacking Defense

todd — Tue, 03 Feb 2009 04:57:45 GMT

cool feature, but more importantly when is IE8 RC2?

IE8 RC1 is obviously not ready for prime time yet.

Also presuming that IE8 RC2 is up to snuff - when will IE8 RTM be released?

thanks

re: Birth of a Security Feature: ClickJacking Defense

armand — Tue, 03 Feb 2009 05:29:47 GMT

since MSFT posted when the RC came out that:

"Our next step, after listening to feedback from the final testing feedback from the community, is releasing the final product. We will be very selective about what changes we make between the Release Candidate and the final product, and very clear in communicating them. We will act on the most critical issues. "

I highly doubt they will release another RC.

Which is truly unfortunate because it means that IE 8 will be released without proper testing, without being hardened, and without giving developers a stable RC to test and build against before IE8 goes RTM.

I will not be happy if IE8 goes RTM without another RC. Its still too buggy and riddled with rendering glitches for me to start coding for it.

re: Birth of a Security Feature: ClickJacking Defense

Tom Stack — Tue, 03 Feb 2009 06:01:16 GMT

Please add onther relase candidate. RC 1 added alot speed/stability improvements to IE. And the fact that you built a new second engine that will slowly replace trident it needs bake time.

Although IE8 RC1 was the slowest of the five browsers, its SunSpider score was approximately 70% faster than IE8 Beta 2's, which was released in August 2008

Source: http://www.networkworld.com/news/2009/012809-ie8-rc1-gains-ground-in.html

This is a massive improvement but if you can give us one more public build or at the very lease onther limted relase build like the PRE RC Partener build please make sure you get it right.

re: Birth of a Security Feature: ClickJacking Defense

Ted — Tue, 03 Feb 2009 06:13:32 GMT

Tom, the "new engine" is still Trident. I'm not sure what you mean by "slowly replace"-- the new standards-mode rendering engine is the default for non-quirks pages.

As for the "slowest of the five"-- you're missing the caveat "at this particular microbenchmark".

re: Birth of a Security Feature: ClickJacking Defense

Tom Stack — Tue, 03 Feb 2009 06:55:07 GMT

Ted:

Thanks for setting me straight when I have heard 2 engines I assumed they would phase out the older engine, I feel stupid :Facepalm:

re: Birth of a Security Feature: ClickJacking Defense

thacker — Tue, 03 Feb 2009 07:58:59 GMT

Price--

Without any condescending or patronizing intent, you have good reason to feel proud and an accomplishment. Thank you.

Two small observations.

One: Possibly consider including a white paper on adding this specific http response header directly within Web content pages and including, for example, adding custom headers for Microsoft and Apache servers and links to it in any discussions of 'click jacking'.

Not all developers have the expertise. Many depend upon canned applications to develop Web content. While 'click jack' injections may be targeted towards high-end e-commerce or HIPAA content, for example, presumption should not be made that even those developers have the immediate expertise.

Secondly, one respondent on Law's post on 'click jacking' made a pertinent suggestion I believe:

"[m]ake HTTPS pages default to X-FRAME-OPTIONS: SAMEORIGIN. [...]"

In my view, that may be due some strong consideration and may prevent problems with many Web sites from 'opting' into such a proactive security feature for no other reason than a substantive number of developers may lack an awareness of the 'click jack' issue.

--------

By the way, PGP causes the RC1 iexplore.exe to crash and burn. Haven't seen any reported documentation of this problem.

re: Birth of a Security Feature: ClickJacking Defense

gabe — Tue, 03 Feb 2009 08:22:17 GMT

i wonder how much trouble would it be for microsoft to port this clicjacking defense back to ie7

re: Birth of a Security Feature: ClickJacking Defense

8675309 — Tue, 03 Feb 2009 09:18:07 GMT

if you dont know the xp/vista ver. is rc2 & the win. 7 beta cp is rc1

re: Birth of a Security Feature: ClickJacking Defense

David W. — Tue, 03 Feb 2009 09:44:50 GMT

"Frame-breaking Javascript is often presented as an anti-ClickJack mechanism, but it is a flawed solution as there are methods to circumvent frame-breaking Javascript."

Can you expand on this? Last I checked, quite a few respectable security people were recommending this. I tried a little Google searching and came up with nothing.

Could you also expand a little on what collaboration Microsoft had with the various web standards communities regarding this problem, before settling on another vendor extension header?

Thanks,

David.

re: Birth of a Security Feature: ClickJacking Defense

David Naylor — Tue, 03 Feb 2009 11:53:16 GMT

@ David W:

That's my understanding too.

JavaScript as a framebreaker is only "flawed" in current versions of IE. All other browsers respect it.

re: Birth of a Security Feature: ClickJacking Defense

Ben 'Cerbera' Millard — Tue, 03 Feb 2009 12:07:21 GMT

From the message on WHATWG:

"1) [...] Adds yet another security measure (along with cross-domain XHR, MSIE8 XSS filters, MSIE P3P cookie behavior, Mozilla security policies) that needs to be employed correctly everywhere to work - which is very unlikely to consistently happen in practice"

Yet that is what IE8 has chosen. Odd.

"3) Add an on-by-default mechanism that prevents UI actions to be taken when a document tries to obstruct portions of a non-same-origin frame."

This would "work by default" whilst allowing legitimate, non-obscuring cross-domain framing to continue. Why not do that?

re: Birth of a Security Feature: ClickJacking Defense

barney — Tue, 03 Feb 2009 16:02:57 GMT

Well thats just brillant! (sic) once again Microsoft has circumvented the standards community to come up with their own way of doing things to ensure that IE Breaks the Web[TM].

BTW, what are these "methods" for breaking Frame-busting JavaScript? Are all browsers suffering from this security breach or just Internet Explorer? If it is just IE, please just fix IE without requiring a meta tag/header as you are fully aware these won't be deployed properly nor completely across the web.

@Ted the EPIC FAIL - which test would you like to offer up that IE excels at beating all other browsers? I haven't seen any. As we've all seen IE can't even open a new tab as fast as other browsers and that happens even before a page is processed.

@Kymberlee Price - we know the "rendering" team still has their work cut out for them before IE8 RC2 but how is the "security" team doing? Is IE8 "ready-to-go" from the security side of things? I'm actually quite impressed at the "lack" of security issues that have been made public surrounding IE8 - it looks like you guys made a tight ship - congrats!

re: Birth of a Security Feature: ClickJacking Defense

Brian LePore — Tue, 03 Feb 2009 17:15:34 GMT

As a person that works for a web development company that hosts our clients using our own custom built CMS I have to ask: how can we implement this (or any of the other HTTP headers that Microsoft and Mozilla have proposed) in such a way that will not result in confusion for our clients or will not prevent them from doing what they want to do? We can build out tools to allow them to administer these headers themselves, but most users aren't going to know to do that.

re: Birth of a Security Feature: ClickJacking Defense

mitchel — Tue, 03 Feb 2009 19:43:28 GMT

I'm trying to put together a test case to file a bug report but IE8 RC1's performance at rendering large tables (e.g. 700 rows) is absolutely horrible - completely locking up my IE browser.

My page is 486k, 1 HTTP request (in standards mode) and takes 1.76s to load and fully render in Firefox. (and while loading the browser is interactive)

The same page on the same PC in IE8 RC1 takes up to 49seconds!!! to render!

(note in both cases the backend took ~141ms to actually run the DB query and start sending the data back to the client)

I should note that the table in question is also only 2 columns wide, with 1 row where the 2 columns are merged (row 3 if it matters) and except for the merged row all other columns contain simple text values, no links, no images, nada.

BEST PART!

Switching to Compatibilty Mode... renders the same table in 1.69 seconds.

re: Birth of a Security Feature: ClickJacking Defense

Dan — Tue, 03 Feb 2009 21:08:59 GMT

Ben 'Cerbera' Millard, you're cherry-picking quotes from the WHATWG text. Only one of the approaches was actually practical: the one IE supports. Trying to have some sort of system which "guesses" whether sensitive content is overlayed is doomed to failure. Or, as the author himself wrote, it's "kludgy" and may break the "legitimate" practices of sites.

David(s)-- you need to do more research. Explain to me how Javascript frame breakers work in browsers where Javascript is off? That's only one of several scenarios; each browser has its own holes here, and for good reason. It's true that security features should be designed in from the start, lest they have obvious holes like those in script-based breakers.

re: Birth of a Security Feature: ClickJacking Defense

Dave — Tue, 03 Feb 2009 22:15:12 GMT

"The “unbeatable” mechanisms would require extensive changes to web application code and it would be difficult to get such recommendations taken seriously."

Classy.

re: Birth of a Security Feature: ClickJacking Defense

steve_web — Tue, 03 Feb 2009 23:49:08 GMT

Resize events on IFRAMES are STILL busted in IE8 RC1. (contrary to the believed scenario in the IE Chat)

Original Bug Report:

https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=390166

New Bug Report (for Vertical Resize):

https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=410707

Can we get some clarification if (a) this regression issue is really fixed internally? and if it will be available in RC2 or RTM?

Thanks,

steve

re: Birth of a Security Feature: ClickJacking Defense

Moichae Xias — Wed, 04 Feb 2009 15:57:14 GMT

@ David Naylor,

"JavaScript as a framebreaker is only "flawed" in current versions of IE. All other browsers respect it."

Nope, JavaScript as a framebreaker is flawed in all browsers, since all browsers have options to turn off javascript. And the most "flawed" browser here would be the popular "Firefox with NoScript" combo, since it blocks most scripts by default.

re: Birth of a Security Feature: ClickJacking Defense

Moichae Xias — Wed, 04 Feb 2009 16:06:05 GMT

@ Ben 'Cerbera' Millard,

"This would "work by default" whilst allowing legitimate, non-obscuring cross-domain framing to continue. Why not do that?"

As you can see from that particular WHATWG discussion thread itself, both Apple and Mozilla developers have voiced some very valid concerns against approach 3) and deemed it impractical

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016299.html

And the Mozilla developer actually supported approach 1) as the potentially best practice

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016340.html

@ barney,

"Well thats just brillant! (sic) once again Microsoft has circumvented the standards community to come up with their own way of doing things to ensure that IE Breaks the Web[TM]."

well, except in this case there's no standards yet and actually most of the standards community agreed IE's way is the most practical way ;)

@ David Naylor,

"JavaScript as a framebreaker is only "flawed" in current versions of IE. All other browsers respect it."

@ Ted,

"As for the "slowest of the five"-- you're missing the caveat "at this particular microbenchmark"."

More like you're missing the caveat "at ALL kinds of performance benchmarks out there". I'd like to see you present us even ONE web browser performance benchmark where IE is not the slowest one, LOL. IE IS the slowest of the five, period.

re: Birth of a Security Feature: ClickJacking Defense

Giorgio Maone — Wed, 04 Feb 2009 16:29:57 GMT

@Moichae Xias & David Nailor:

"Nope, JavaScript as a framebreaker is flawed in all browsers, since all browsers have options to turn off javascript."

Yes, but no other browser except IE gives this option in the hands of *the attacker*, allowing him to disable JavaScript on the victim site with {IFRAME SECURITY=restricted} ;)

"And the most "flawed" browser here would be the popular "Firefox with NoScript" combo, since it blocks most scripts by default."

This statement is utterly false for two simple reasons:

1) NoScript emulates frame-busting: when a frame breaker script is detected on a script-blocked page, NoScript opens the page as a top level anyway, http://noscript.net/faq#qa7_5

2) NoScript already provides complete Clickjacking protection, frame busting or not, with ClearClick which is the only available implementation of something similar to the #3 Zalewski's (favorite) proposal, http://noscript.net/faq#clearclick

And however, http://hackademix.net/2009/01/29/x-frame-options-in-firefox/

re: Birth of a Security Feature: ClickJacking Defense

thacker — Wed, 04 Feb 2009 19:05:48 GMT

Maone--

Glad to see your input. Thanks for the NoScript extension for Firefox. It is the primary reason why I use Firefox.

Why not develop a similar add-on for IE? [Probably a very logical explanation for such.]

If needed or necessary, Microsoft why not offer assistance for such, --technical, financial or otherwise?

re: Birth of a Security Feature: ClickJacking Defense

Giorgio Maone — Wed, 04 Feb 2009 20:24:34 GMT

"Why not develop a similar add-on for IE?"

Because IE is not nearly an extensible and hackable development platform as Firefox.

You know, NoScript is entirely written in JavaScript and as such is really easy to maintain and evolve quickly, which is a key strength for a security tool.

Furthermore, NoScript works on the edge of many internal and often undocumented browser mechanisms, therefore having all the source code at hand is almost indispensable.

re: Birth of a Security Feature: ClickJacking Defense

Moichae Xias — Thu, 05 Feb 2009 11:11:33 GMT

@ Giorgio Maone,

"This statement is utterly false for two simple reasons:

1) NoScript emulates frame-busting: when a frame breaker script is detected on a script-blocked page, NoScript opens the page as a top level anyway, noscript.net/faq#qa7_5

Nope, actually that statement of mine is utterly true while the two "reasons" from you are utterly false, because of just one simple test :

http://img152.imageshack.us/img152/8175/nstestlw5.png

and this is done with one of the most popular frame-busting code here:

<html>

<head>

if (top!= self) top.location.href = location.href;

</script>

</head>

<body>

You should only see this!

</body>

</html>

which works fine in firefox with no NoScript.

and for your "reason 2)", since I was not talking about Clickjacking protection, but replying to David Naylor's "flawed JavaScript as a framebreaker" comment, so yes framebusting is indeed most "flawed" in the Firefox+NoScript combo, and your "reason 2)" is completely irrelevant to that statement of mine.

The test is done with latest Firefox 3.06 + NoScript 1.9, defualt settings.

PS: BTW, your "ClearClick" in NoScript mentioned in your "reason 2)" doesn't show any warning against my Clickjacking tests which uses a small div "window" to show only a small certain portion of the framed page to the user, so it seems your statement about it "provides complete Clickjacking protection" is utterly false too.

re: Birth of a Security Feature: ClickJacking Defense

Giorgio Maone — Thu, 05 Feb 2009 14:43:46 GMT

@Moichae Xias:

could you please provide live PoC pages to back your claims?

TIA

re: Birth of a Security Feature: ClickJacking Defense

IE8 Tester — Thu, 05 Feb 2009 17:01:09 GMT

The new clickjacking protection is USELESS.

Here is a small and straighforward PoC code to bypss it:

http://huaidan.org/archives/2779.html

In fact you only need one line of JS to break it:

onclick="this.href='http://www.yahoo.com'"

re: Birth of a Security Feature: ClickJacking Defense

Giorgio Maone — Thu, 05 Feb 2009 17:27:35 GMT

@IE8 Tester:

I could *partially* agree on the first statement (it's *partially* useless, until every vulnerable site adopts X-FRAME-OPTIONS, and anyway it cannot protect against plugin-based clickjacking).

However that "PoC" you linked means absolutely nothing, it's not clickjacking but just a joke like this one:

http://hackademix.net/2009/01/31/all-that-clickjazz/

re: Birth of a Security Feature: ClickJacking Defense

Michael Becker — Sat, 14 Feb 2009 10:54:42 GMT

Hopefully a RC2 will be released soon. I experienced that a background image (in frames) is not dispayed properly every time.

re: Birth of a Security Feature: ClickJacking Defense

Kymberlee Price — Sat, 14 Mar 2009 02:44:16 GMT

Whoa, I’ve got a lot of comments to respond to. My sincere apologies for the tardiness.

@thacker – there is more developer guidance on how to implement the header changes in my colleague Eric Lawrence’s ClickJacking blogpost. http://blogs.msdn.com/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx However, the suggestion of our providing more prescriptive guidance regarding implementation and appropriate scenarios for adoption (such as https sites) is not out of the question. I am currently working on a plan to try and scope the real-world threat that ClickJacking poses and then do outreach to vulnerable websites to help their web devs implemenet the necessary changes.

@gabe – backporting a feature with UI and localization changes is definitely hard. Not saying we won’t do it, but not saying we will either. We continue to evaluate our options here.

@David W. – answering your comments in reverse, we had a conference call in December 2008 that we invited several browser vendors to participate in where we discussed the threat and what our proposed solution was, looking for critical feedback and a community driven, best of breed solution that could be widely adopted by multiple browsers. Because ClickJacking is such a new security threat that standards bodies didn’t even have draft proposals available and IE8 was so far along in its development cycle, we felt this was a short term solution we could provide web developers while we work with other vendors and standards bodies on a standard solution (which typically takes awhile).

Re: how to circumvent frame breaking javascript, well, providing too much detail kind of breaks us into jail with the Bad Guys. So please forgive me for not elaborating.

@Ben ‘Cerbera’ Millard – proposal 3 might sound simple but isn’t easy in design/implementation given some of the same concerns the proposal author and @Dan have pointed out re: breaking legitimate sites. Given these concerns we were not confident we could deliver that proposed solution with the quality, performance, and compatibility we wanted in the RC1 release window.

@barney – please see my replies to @David W. re: standards and circumventing frame breaking. Re: the security team, thanks! Tons of the folks I’ve talked to in IE, regardless of whether they are officially on the security team or not, are passionate about making the right security decisions for their features and the product.

@Brian LePore – hopefully the link I provided @thacker helps, and we’ll work on getting more documentation out to folks soon…

@steve_web – https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=410707 – yes, we’ve fixed it.

@Moichae Xias – thanks for the comments. :)

@Giorgio Maone – no debate, NoScript provides protection against ClickJacking and puts it in the hands of the users to manage, while our approach lies with the providers of content sensitive to ClickJacking. Both require adoption by someone sitting at a computer – either the web dev or the user – to provide any sort of protection. So while FireFox users concerned about ClickJacking can leverage NoScript, web devs are helpless to get their users to install FireFox with NoScript. At the end of the day I just don’t see a perfect solution yet for a threat that was just identified a few months ago. Moving forward, hopefully browser vendors can work together on this with standards bodies to make it easier on web devs and users alike.

tech notes: ie8 and the padded cell mentality

fractalnavel — Sat, 11 Apr 2009 23:52:44 GMT

overdoing the security without an escape: "This content cannot be displayed in a frame"; tumblr.com video handling ?