IE8 and ClickJacking

[Update: NoScript's author disagrees with the claims about it in this blog. Click here for more.]

Security researchers argue about "clickjacking." It's a term used to describe attacks vaguely defined as tricking the user into clicking on one thing when it appears they are clicking on another.

Michal Zalewski of Google has an example in this security mailing list post that puts it in a little more technical context:

a malicious page in domain A may create an IFRAME pointing to an application in domain B, to which the user is currently authenticated with cookies. The top-level page may then cover portions of the IFRAME with other visual elements to seamlessly hide everything but a single UI button in domain B, such as "delete all items", "click to add Bob as a friend", etc. It may then provide own, misleading UI that implies that the button serves a different purpose and is a part of site A, inviting the user to click it. Although the examples above are naive, this is clearly a problem for a good number of modern, complex web applications.
The clicking trick is the clickjacking. The underlying attack, where the request is misleadingly placed to domain B, is usually known as a CSRF (Cross Site Request Forgery). There are many techniques to implement the clickjacking part of the attack. Javascript is not required for the attack, so NoScript won't protect you.

Zalewski, who prefers the term "UI Redress" attacks, thinks that any sufficiently feature-rich browser will be vulnerable to attacks of this sort. It's inherent in the current design of browsers and HTML.

There seems to be a consensus that it's up to web applications to protect themselves against such attacks by scrutinizing requests from clients. Many try to do this with "frame busting," generally with script to stop their pages from loading in a frame. Since this is in script there are ways to defeat it.

With Internet Explorer 8 Microsoft will try to help applications block at least some clickjacking with a new HTTP response header named X-FRAME-OPTIONS. If this header is sent to the browser with a value of DENY then IE8 will block all attempts to load it in a frame. If the value is SAMEORIGIN then it will only load the page in a frame if the request came from the same domain as the page to be loaded. Microsoft invites other browser vendors to implement the feature.

Zalewski examined a possibility something like this in that security mailing list post. He has a number of objections to it; web authors have to know how to use it properly, using it then blocks access to legitimate cross-site framing, and the possibility of HTTP header bloat. He seems to prefer an app-level construct, which means a new HTML element, which would be quite difficult to bring about, even for Google.

But his favorite solution is an internal (to the browser) security structure which looks for conditions of "UI Redress" and blocks UI input. As he says it has the advantage of working on all sites by default, but even he calls it "Moderately complex and kludgy." I think he's understating the complexity, and it sounds like a recipe for mysterious error and incorrect behaviors.

The Microsoft solution, as critics point out in this Network World article, will inevitably leave large numbers of users and sites unprotected, but this is a weak criticism. True solutions are necessarily disruptive and would probably break a lot of code. And the Network World article is inaccurate in claiming that clickjacking requires script on the client; it does not, and NoScript will not necessarily protect you. (See the ha.ckers clickjacking details page for more on this.)

Clickjacking won't go away because of the IE8 changes and any effect those changes have will take a long time to be realized, but it's not nothing. Probably major sites, like, will implement it quickly in order to protect themselves, and this protection will then be available to IE8 users. Eventually, as with every other version of IE, most users will move over. Users and sites that lag will remain unprotected, but that's hardly a new problem on the Internet.

blog comments powered by Disqus