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.
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 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:
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 https://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 https://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.
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
Anonymous
January 27, 2009
IE8 in Win7 doesn't start with an empty cookie jarAnonymous
January 28, 2009
> 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?Anonymous
January 28, 2009
We are working on resolving the commenting issue asap. Sorry for the disruption.Anonymous
January 28, 2009
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.Anonymous
January 28, 2009
testing testing testing... please ignore. typing enough so this won't be flagged as spam. blah blah blah blah blahAnonymous
January 28, 2009
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. :-(( GervAnonymous
January 28, 2009
@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.Anonymous
January 28, 2009
@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? GervAnonymous
January 28, 2009
Since the release of Internet Explorer 8 beta 2, we’ve listened, watched and learned a lot about howAnonymous
January 28, 2009
@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.Anonymous
January 28, 2009
Eric: Ah, right. Thanks for the explanation :-)Anonymous
January 28, 2009
IEBlog も一気呵成でお疲れ様ですが。 IE8 プレテストスイート 的な Windows Internet Explorer Testing Center...Anonymous
January 29, 2009
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?Anonymous
January 29, 2009
The comment has been removedAnonymous
January 29, 2009
The comment has been removedAnonymous
January 29, 2009
> 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.Anonymous
January 30, 2009
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.Anonymous
January 31, 2009
@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.Anonymous
January 31, 2009
(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.)Anonymous
January 31, 2009
Dumb question... The http header has to be capitalized? RegardsAnonymous
February 01, 2009
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.
Anonymous
February 01, 2009
@Doubt Guy: Nope, HTTP Header names are case-insensitive per RFC2616.Anonymous
February 02, 2009
Hi, my name is Kymberlee Price, and I recently joined the Internet Explorer team as a Security ProgramAnonymous
February 02, 2009
Kymberlee Price, Security Program Manager for IE8 posts about Clickjacking feature in IE8 RC1 ......Anonymous
February 03, 2009
Clickjacking is one of those nightmare situtations for your customers. And the attack on your Web siteAnonymous
February 03, 2009
IE8 team has this awesome post on this topic which you can read here ! Enjoy :-) Yours, RohanAnonymous
February 05, 2009
Изменения взаимодействия с пользователем в IE8 RC1 После выпуска Internet Explorer 8 Beta 2, мы внимательноAnonymous
March 10, 2009
4 Reasons We Must Redefine Web Application SecurityAnonymous
March 22, 2009
Nejjednodušší odpověď je obojí. Ale pokud bych si jako koncový uživatel i jako vývojář měl dnes vybrat,Anonymous
March 22, 2009
Nejjednodušší odpověď je obojí. Ale pokud bych si jako koncový uživatel i jako vývojář měl dnes vybrat,Anonymous
March 25, 2009
Over the last year, we’ve published two posts about how the IE8 SmartScreen ® filter helps to preventAnonymous
April 09, 2009
    Internet Explorer 8을  계획했었을 때, 보안팀은 현실에 일어나는 일반적인 공격과 공격자가 무엇을 다음 주의대상으로 하는지 경향을 분석했습니다.Anonymous
April 11, 2009
overdoing the security without an escape: "This content cannot be displayed in a frame"; tumblr.com video handling ?Anonymous
April 21, 2009
I attended Scott Charney’s keynote this morning at RSA – Moving Towards End to End Trust