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