IE8 Security Part VII: ClickJacking Defenses


As we planned Internet Explorer 8, our security teams analyzed the common attacks in the wild and the trends that suggest where attackers will be focusing their attention next. Over the course of IE8’s development, we’ve also worked closely with those in the security research community to stay on top of new classes of threats. One of the most subtle and interesting web application security vulnerabilities is called Cross Site Request Forgery (CSRF); security researcher Jeremiah Grossman calls CSRF “the sleeping giant” of web vulnerabilities. As Jeremiah notes, preventing CSRF attacks is hard because there’s generally no easy fix. The architectural underpinnings of the browser security model are designed to allow for interaction with multiple websites simultaneously, and seamless navigation between unrelated websites, but these are the very capabilities that CSRF attacks seek to exploit. With the migration of private data and other high value targets from end-users’ PCs to popular web applications, interest in CSRF and other web application vulnerabilities will only continue to grow.

As we designed Internet Explorer 8, we had to be very careful not to increase the browser’s attack surface for CSRF attacks. IE8’s new XDomainRequest object, for instance, allows cross-domain communication upon explicit permission of the server, but contains specific restrictions to ensure that new types of CSRF attacks are not made possible. End-users can mitigate the impact of CSRF attacks by logging out of sensitive websites when not in use, and by browsing in independent InPrivate Browsing sessions. (InPrivate sessions start with an empty cookie jar, so cached cookies cannot be replayed in CSRF attacks.)

Ultimately, however, web applications must be built to prevent CSRF vulnerabilities. Well-designed Web applications often protect themselves with challenge tokens or similar strategies that enable detection of malicious requests that were not intentionally sent by the victim user. Unfortunately, challenge tokens and similar strategies are subject to vulnerabilities. The first vulnerability is cross-site scripting (XSS). If a token-protected web application contains a cross-site scripting vulnerability, it’s likely that the security token can be stolen and the CSRF attack can occur. Fortunately, Internet Explorer 8 includes an XSS Filter and several other features that help prevent XSS attacks that could otherwise be used to steal CSRF-blocking challenge tokens.

Last fall, researchers Robert Hansen and Jeremiah Grossman gave a talk on a second vector that enables CSRF, known as ClickJacking. ClickJacking is a term which encompasses multiple techniques that can be used to trick the user into unwittingly clicking an obscured or hidden web element, usually resulting in an unwanted transaction. A successful ClickJacking attack could circumvent CSRF protections that attempt to confirm transactions with the user. For instance, consider a simple web shop which uses cookies for authentication and offers one-click purchases.

IE8 displaying a mock web shopping site, there is a picture of a laptop computer in view

A malicious site elsewhere on the web could construct a page that forces a victim page from the legitimate shop into an IFRAME, and overlay critical portions of that frame with misleading text and images.

The malicious webshop.  The picture of the laptop computer is covered with a picture of a cat.

The user might be tricked into clicking into the shop’s page unknowingly, and if they were already logged into the shop, an unwanted transaction might occur:

The malicious webshop. Text is displayed which indicates that the user has just purchased a laptop computer.

Obviously, this is a pretty simple ClickJacking attack, but more sophisticated versions do exist.

While various mitigations for ClickJacking have been proposed, each entails a set of tradeoffs which can impact compatibility, user-experience, or require significant changes to existing standards. Currently, the simplest and most broadly-used mechanism to defeat ClickJacking attacks is called frame-busting, and it works by simply preventing vulnerable pages from being framed. Unfortunately, typical frame-busting mechanisms rely on script and as a result can be defeated in various ways.

As disclosed to other browser vendors in early December, the Internet Explorer 8 Release Candidate introduces a new opt-in mechanism that enables web applications to mitigate the risk of ClickJacking on vulnerable pages by declaring that those pages may not be framed.

Web developers can send a HTTP response header named X-FRAME-OPTIONS with HTML pages to restrict how the page may be framed. If the X-FRAME-OPTIONS value contains the token DENY, IE8 will prevent the page from rendering if it will be contained within a frame. If the value contains the token SAMEORIGIN, IE will block rendering only if the origin of the top level-browsing-context is different than the origin of the content containing the X-FRAME-OPTIONS directive. For instance, if http://shop.example.com/confirm.asp contains a DENY directive, that page will not render in a subframe, no matter where the parent frame is located. In contrast, if the X-FRAME-OPTIONS directive contains the SAMEORIGIN token, the page may be framed by any page from the exact http://shop.example.com origin.

When rendering is blocked by the X-FRAME-OPTIONS policy, a local error page is presented that explains the restriction and provides a link which opens the frame in a new window. When displayed in a new window rather than a sub-frame, content is no longer subject to ClickJacking.

The Malicious webshop, however, this time only the cat picture shows, the order button from the real webshop is not displayed.  There is an error message indicating that the content could not be displayed in a frame.

By using the X-FRAME-OPTIONS directive to protect sensitive anti-CSRF pages, web developers can immediately help mitigate web application attacks for IE8 users. It is my hope that the X-FRAME-OPTIONS directive will be implemented by other browsers as an easily-deployed, highly-compatible mitigation against the threat of ClickJacking. In the longer term, I expect that security researchers and web standards bodies will continue to innovate in the design of browser-enforced web application security policies. We look forward to working with them to frame this and future ClickJacking defenses within the context of a larger security policy feature in future browser versions.

Thanks!

Eric Lawrence
Program Manager

Update 3/30/2010: I’ve posted some Best Practices for using X-Frame-Options over on the IEInternals blog.

Comments (34)

  1. Anonymous Hippopatamus says:

    IE8 in Win7 doesn’t start with an empty cookie jar

  2. Analgesia says:

    > Unfortunately, typical frame-busting mechanisms rely on script and as a result can be defeated in various ways.

    I’m curious as to how one can defeat a simple frame-busting script. From what I read on the web it can’t be done. Anyone found any proof of concept?

  3. ieblog says:

    We are working on resolving the commenting issue asap.  Sorry for the disruption.

  4. RBJ says:

    Can you guys please fix the zooming in/out when viewing huge images?

    it lags a lot, firefox 3 doesn’t have this problem.

    here is a picture for example:

    http://spaceflight.nasa.gov/gallery/images/shuttle/sts-109/hires/sts109-729-072.jpg

    open it in IE8 RC1, wait for it to load completely then see how extremely laggy zooming get.

  5. test comment says:

    testing testing testing…  please ignore.  typing enough so this won’t be flagged as spam.  blah blah blah blah blah

  6. Gerv says:

    Instead of inventing a specific header for just this problem, did you guys consider adding a stanza to something more general, like Content Security Policies?

    http://people.mozilla.org/~bsterne/content-security-policy/details.html

    A "parent-src" option there would achieve the same thing, but would also allow you to extend your implementation to support the other desirable things in CSP for the prevention of other cross-site content issues. At this rate, we are going to have a header for each security issue we discover with the web. X-Prevent-CVE-2009-1245: yes?

    A small amount of discussion with other vendors prior to your announcement would have allowed ideas like this to be considered much more easily. You now have a problem in that if you do decide that not everything useful is invented at Microsoft and adapt to use a more generic mechanism such as CSP, you have to tell everyone you’ve changed the name of the header you’ve chosen. :-((

    Gerv

  7. EricLaw [MSFT] says:

    @Gerv: Yes, making this a part of Content Security Policy and the like was considered, a point I alluded to in the conclusion.  The reality is that adding CSP-like mechanisms is out of scope for IE8, and this is an issue that we wanted to address in the short-term.

    As noted in the post, we did have conversations with other browser venders in December about what we were doing and why. As for the suggestion that the "Don’t frame me" header is somehow a unique Microsoft invention– that’s not the case, as demonstrated by links in the post.  

    @Anonymous Hippopatamus: On RC1 of IE8 and later, InPrivate starts with an empty cookie jar.  This wasn’t true in Beta builds.

    @Analgesia: There are a number of techniques that can cause frame-busting scripts to fail.  For instance, if the user has scripting disabled, or, if the frame has the SECURITY=RESTRICTED attribute set, etc.

  8. Gerv says:

    @EricLaw: thanks for replying so quickly 🙂 I’m not asking you to implement CSP, just to get as far as saying "that seems like a good idea" and therefore pick a CSP-compatible syntax rather than inventing another header. So:

    X-Content-Security-Policy: parent-src none

    rather than

    X-Frame-Options: deny

    and the same for "self" mapping to your "sameorigin". This would require, I would assume, only a few string changes on your side from what you currently have already, and yet would mean we didn’t get proliferating headers solving every different kind of security issue, causing web developer confusion and response bloat. I can imagine, for example, a "CSP Constructor" website which made an X-CSP header based on the requirements you entered.

    BTW, dveditz commented in our bug https://bugzilla.mozilla.org/show_bug.cgi?id=475530 that "sameorigin" is the same as "deny" unless you don’t trust your own site – and if your own site is untrustworthy, they could use XHR to get the data anyway. So the two are effectively equivalent. Is that your understanding?

    Gerv

  9. IEBlog says:

    Since the release of Internet Explorer 8 beta 2, we’ve listened, watched and learned a lot about how

  10. EricLaw [MSFT] says:

    @Gerv: The comment: "We look forward to … a larger security policy feature" was meant to suggest that I think CSP is a good idea.  The problem in targeting a moving spec is that if we ship something that isn’t compatible with the future evolution of that spec, we’re inevitably pilloried for hurting adoption of that spec.  So until we’re ready to support a stable CSP spec, we’re surgically addressing this vector.

    The question of when to use DENY and when to use SAMEORIGIN is an interesting one.  It comes down to the expected use case for the page protected with the directive.  If you never expect the page to be framed, you should use DENY.  If you expect the page to be framed only by pages on your server (e.g. it’s part of a FRAMESET) then you’ll want to use SAMEORIGIN.

    Keep in mind that if you use SAMEORIGIN, IE8 will forbid framing only if the *top-level* origin FQDN (aka what you see in the address bar) does not match the FQDN of the page that demanded SAMEORIGIN.

    So, if your site permits hosting of arbitrary frames (say you’ve got a page like:  http://victimSite.com/FrameIt.asp?embedframeURL=Attacker.com/eviloverlay), it should NOT use SAMEORIGIN and should use DENY instead.  

    Otherwise, VictimSite is vulnerable to ClickJacking by Attacker.com by virtue of the fact that the top-level document (victimsite.com/Frameit.asp) and the grandchild frame (victimsite.com/target.asp) are same-origin.

  11. Gerv says:

    Eric: Ah, right. Thanks for the explanation 🙂

  12. barlog says:

    IEBlog も一気呵成でお疲れ様ですが。 IE8 プレテストスイート 的な Windows Internet Explorer Testing Center…

  13. Tino Zijdel says:

    X-FRAME-OPTIONS seems to be a bit limited since you cannot explicitly allow framing by a set of ‘trusted’ domains. With regards to SAMEORIGIN; does document.domain play a part in that (e.g. when you set that for domain relaxation?).

    Another question is: can you also set it as a META http-equiv?

  14. EricLaw [MSFT] says:

    @Tino: Yes, the fact that X-FRAME-OPTIONS does not support a list of domains is a limitation.  As noted previously, I believe that framing restrictions will eventually become a part of a richer ACL’ing model.  For now, we believe the feature has significant value for the many cases where it’s reasonable to host certain CSRF-sensitive pages only in their origin domain.

    Document.domain does not figure in; the actual origin FQDN is used rather than document.domain. This reduces attack surface against the various hacks that might be attempted otherwise (e.g. evil.users.spaces.live.com tries to CJ against live.com)

    At the moment, our recommendation is to use the HTTP Header.  In the future, more formal guidance will be available on MSDN in the developer documentation.

  15. Dan Veditz says:

    @Tino: I suspect all of the current browser vendors deeply regret document.domain and will strenuously resist adding new capabilities to that gaping hole in the same-origin policy. Document.domain is unnecessary, the uses it was invented to enable can be accomplished in many other ways with modern browsers.

  16. fearphage says:

    > I’m curious as to how one can defeat a simple frame-busting script. From what I read on the web it can’t be done. Anyone found any proof of concept?

    This can be defeated only with IE’s non-standard html extension to my knowledge: [IFRAME security="restricted"] That will prevent the iframe from "breaking out". So they created a workaround to fix a problem they created. Fantastic.

  17. Dan says:

    fearphage, no, there are several other ways to defeat framebusters (do a little research).

    And you’re completely forgetting that the user might have Javascript disabled.

  18. Randall says:

    @EricLaw: I see that a lot of ideas have been proposed already, and I know IE8’s feature set is locked down.  

    For the future, one idea I haven’t seen is stricter default policies when the target of a cross-site frame is HTTPS.  Maybe secure form submissions from those frames pop up a warning dialog.  

    HTTPS is an interesting special case because it would have less compatibility impact (most ads aren’t secure) and secure sites tend to be the type that most need security-by-default.

    Naturally, you’d have to be convinced that the security gain is worth the devel and compatibility cost; seemed interesting, anyway.

  19. Randall says:

    (Or, more aggressively: make HTTPS pages default to X-FRAME-OPTIONS: SAMEORIGIN.  Again, you’d have to know what it would break and decide if it’s worth the inevitable developer wrath.)

  20. Doubt Guy says:

    Dumb question…

    The http header has to be capitalized?

    Regards

  21. thacker says:

    Randall–

    "For the future, one idea I haven’t seen is stricter default policies when the target of a cross-site frame is HTTPS.  Maybe secure form submissions from those frames pop up a warning dialog."

    "(Or, more aggressively: make HTTPS pages default to X-FRAME-OPTIONS: SAMEORIGIN.  Again, you’d have to know what it would break and decide if it’s worth the inevitable developer wrath.)"

    Thanks.  I have been waiting for some explanation and points of discussion on such.

    Your last suggestion appears to be an excellent point. Developer wrath or not, the first responsibility for security lies with the developer and the content and without passing the proverbial buck onto the browser ‘sandbox’.

    ———-

    In terms of IE8 RC1, crashes and off-topic points, it appears that possibly Adobe’s PDF add-ons are causing the RC1 to crash. Whatever major plug-ins/addons cause such problems, it is not good.

  22. EricLaw [MSFT] says:

    @Doubt Guy: Nope, HTTP Header names are case-insensitive per RFC2616.

  23. IEBlog says:

    Hi, my name is Kymberlee Price, and I recently joined the Internet Explorer team as a Security Program

  24. Bink.nu says:

    Kymberlee Price, Security Program Manager for IE8 posts about Clickjacking feature in IE8 RC1 ……

  25. Clickjacking is one of those nightmare situtations for your customers. And the attack on your Web site

  26. IE8 team has this awesome post on this topic which you can read here ! Enjoy 🙂 Yours, Rohan

  27. Изменения взаимодействия с пользователем в IE8 RC1 После выпуска Internet Explorer 8 Beta 2, мы внимательно

  28. 4 Reasons We Must Redefine Web Application Security

  29. Nejjednodušší odpověď je obojí. Ale pokud bych si jako koncový uživatel i jako vývojář měl dnes vybrat,

  30. Nejjednodušší odpověď je obojí. Ale pokud bych si jako koncový uživatel i jako vývojář měl dnes vybrat,

  31. IEBlog says:

    Over the last year, we’ve published two posts about how the IE8 SmartScreen ® filter helps to prevent

  32.     Internet Explorer 8을  계획했었을 때, 보안팀은 현실에 일어나는 일반적인 공격과 공격자가 무엇을 다음 주의대상으로 하는지 경향을 분석했습니다.

  33. fractalnavel says:

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

  34. I attended Scott Charney’s keynote this morning at RSA – Moving Towards End to End Trust