Birth of a Security Feature: ClickJacking Defense
Hi, my name is Kymberlee Price, and I recently joined the Internet Explorer team as a Security Program Manager for IE8, working with Eric Lawrence. Prior to this I spent five years in Microsoft's Security Engineering & Communications team (MSEC) where I founded the Security Researcher Community Outreach team in 2003 and drove the first three BlueHat events. I joined IE at the perfect time to watch a new security feature be created, and thought customers and security researchers might be interested to learn more about how that happened.
In September, I moved into my new office, the sun was shining (even in Seattle), and Robert Hansen and Jeremiah Grossman were preparing to deliver a talk at an OWASP meeting in New York on a new security threat that they called ClickJacking. As details started coming in over the next few weeks, so did the meeting requests. I attended a number of brainstorming meetings with web security experts Billy Rios, Bryan Sullivan, David Ross, Eric Lawrence, Spencer Low, and members of Microsoft Research such as Helen Wang. The highlights of those meetings:
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. And fundamentally frame breakers were never meant to be ClickJacking mitigations. If you don’t design something to prevent a security vulnerability, odds are that it doesn’t do a very good job of doing it accidentally.
Browser configuration options are limited.Short of using Security Zones or add-ons to disable frames and script (massively impairing browser utility), browser users are very vulnerable to this type of attack.
So we found ourselves in a situation where IE didn't have a workable mitigation for end-users to protect themselves, and we knew of ways to circumvent virtually everything that a server could try to do to prevent ClickJacking without additional help from the browser platform. The “unbeatable” mechanisms would require extensive changes to web application code and it would be difficult to get such recommendations taken seriously.
It was time to look at developing a new solution. David Ross prototyped a tool that on cursor hover would delay the user's ability to click through for 5 seconds while showing the user what site/domain they were ACTUALLY about to click on. While this would certainly let the user make an informed decision before clicking, it would also create a significant user impact to web browsing. ClickJacking is actually a fairly narrow attack that represents a subset of the significantly larger cross-site-request-forgery problem. If a website doesn’t protect itself from CSRF threats, attackers need not bother with ClickJacking at all. Given the nature of the threat, creating a defense mechanism that puts a heavy burden on the browsing experience for users is unacceptable.
Ultimately, we concluded that the best ClickJacking defense feature we could add to IE8 during product development would be to allow the content owner to decide if their content should be framed or not, and for the browser to enforce that. This solution was also proposed by Michael Zalewski on the WHATWG forum.
Eric and I started discussing potential ClickJacking defenses with security researchers at conferences and consistently got feedback that the 'don't frame me' opt-in solution was reasonable as opt-out options all came with significant compatibility and usability issues. But we still wanted to get more feedback from web security experts so we communicated with several browser vendors in early December, creating an open forum to discuss the problem and propose solutions. We shared our plans, asked for feedback, and encouraged other browsers to adopt a similar model in the near term—we want all users to be protected, regardless of browser!
Now that RC1 is out and the ClickJacking defense feature is public, our work is not done. As an opt-in protection measure, web developers need to make a change to their code to activate this defense for users. That means educating our field consultants and account managers. I'll be presenting at TechReady 8 next week, and my first Call To Action bullet point is for our front line field employees to help developers understand how to opt in and take advantage of this. My second bullet point is to help developers create a migration plan to get off legacy browser platforms - the architectural changes and security investments we have made in recent browsers are significant.
-Kymberlee Price
Program Manager
Comments
Anonymous
February 02, 2009
PingBack from http://www.anith.com/?p=4752Anonymous
February 02, 2009
The comment has been removedAnonymous
February 02, 2009
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.Anonymous
February 02, 2009
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.Anonymous
February 02, 2009
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".Anonymous
February 02, 2009
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:Anonymous
February 02, 2009
The comment has been removedAnonymous
February 02, 2009
i wonder how much trouble would it be for microsoft to port this clicjacking defense back to ie7Anonymous
February 02, 2009
The comment has been removedAnonymous
February 02, 2009
"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.Anonymous
February 02, 2009
@ David W: That's my understanding too. JavaScript as a framebreaker is only "flawed" in current versions of IE. All other browsers respect it.Anonymous
February 02, 2009
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?Anonymous
February 03, 2009
The comment has been removedAnonymous
February 03, 2009
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.Anonymous
February 03, 2009
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.Anonymous
February 03, 2009
The comment has been removedAnonymous
February 03, 2009
"The “unbeatable” mechanisms would require extensive changes to web application code and it would be difficult to get such recommendations taken seriously." Classy.Anonymous
February 03, 2009
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, steveAnonymous
February 03, 2009
@ 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.Anonymous
February 04, 2009
@ 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." 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. @ 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.Anonymous
February 04, 2009
@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:
- 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
- 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/
Anonymous
February 04, 2009
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?Anonymous
February 04, 2009
"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.Anonymous
February 04, 2009
The comment has been removedAnonymous
February 04, 2009
@Moichae Xias: could you please provide live PoC pages to back your claims? TIAAnonymous
February 05, 2009
The comment has been removedAnonymous
February 05, 2009
@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/Anonymous
February 13, 2009
Hopefully a RC2 will be released soon. I experienced that a background image (in frames) is not dispayed properly every time.Anonymous
March 13, 2009
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.Anonymous
April 11, 2009
overdoing the security without an escape: "This content cannot be displayed in a frame"; tumblr.com video handling ?