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 (30)

  1. todd says:

    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

  2. armand says:

    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.

  3. Typhoon87 says:

    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.

  4. Ted says:

    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".

  5. Typhoon87 says:

    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:

  6. thacker says:

    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.

  7. gabe says:

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

  8. 8675309 says:

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

  9. David W. says:

    "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.

  10. David Naylor says:

    @ David W:

    That’s my understanding too.

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

  11. 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?

  12. barney says:

    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!

  13. Brian LePore says:

    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.

  14. mitchel says:

    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.

  15. Dan says:

    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.

  16. Dave says:

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

    Classy.

  17. steve_web says:

    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

  18. Moichae Xias says:

    @ 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.

  19. Moichae Xias says:

    @ 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.

  20. @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/

  21. thacker says:

    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?

  22. "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.

  23. Moichae Xias says:

    @ 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

    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, noscript.net/faq#clearclick"

    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>

    <title></title>

    <script language="javascript" type="text/javascript">

    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.

  24. @Moichae Xias:

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

    TIA

  25. IE8 Tester says:

    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‘"

  26. @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/

  27. Michael Becker says:

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

  28. 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.

  29. fractalnavel says:

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