hackademix.net

Microsoft released Internet Explorer 8 RC1 yesterday with the usual big fanfare, and one of its main marketing punchlines is its “exclusive” clickjacking protection:

Microsoft Adds Clickjacking Protection to IE8 RC1

[…]
One major security update to block Web attacks known as “clickjacking” that the company said makes IE8 the only Web browser to offer such protection.
[…]
The security feature that thwarts clickjacking in IE8 RC1 allows Web-site content owners to put a tag in a page header that will help detect and prevent clickjacking. If a site that uses the IE8 tag detects clickjacking, it will give Web users an error screen letting them know that the content host has chosen not to allow that content, and gives them the option to open the content in a new window that is protected from the attack.
(PC World)

Microsoft IE8 Hits RC1 Milestone, Stops Clickjacking

[…]
RC1 also includes protection against “Clickjacking,” a ploy to get users to click on account buttons while covering the actual site being clicked on using a frame – the first browser available to counter this type of threat, Pratt said.
(PC Magazine)

Microsoft Goes After Clickjacking in IE8

[…]
While offering few technical details of its methods for stopping clickjacking, Microsoft appears to have not only tried to address the browser-based issues, but also sought out the help of Web site owners to make IE8 less vulnerable to the attacks.
[…]
Now, it will remain to be seen whether or not the features offered in the IE8 RC browser have an effect in preventing clickjacking attacks, but you have to give the guys in Redmond credit.
(Security Watch)

Hype aside, forgiving Microsoft’s habit of forgetting precursors of their “first and unique” technologies, what can we infer from the “few technical details”?

At this moment, Tue Jan 27 2009 15:20:49 GMT+0100, searching for Clickjacking on the Microsoft Developer Network I can find just 1 result, i.e. the Internet Explorer 8 Release Candidate Now Available IEBlog’s post, and it doesn’t give away any more juice:

We’ve worked closely with people in the security community to enable consumer-ready clickjacking protection. Sites can now protect themselves and their users from clickjacking attacks “out of the box,” without impacting compatibility or requiring browser add-ons.

Putting all these pieces together, IE8’s clickjacking countermeasure seems to be a “tag” (or a HTTP header, or both) which “web content owners” must attach to the page(s) of theirs to be protected.
So it’s not about users protecting themselves: “Sites can now protect themselves and their users”.
Ooops, we knew sites could already “protect themselves and their users” last week, last year or even one decade ago, and in a more or less browser-independent way too. That’s called frame busting, and it’s done with a simple JavaScript one-liner. Therefore my guess, documentation pending, is that IE8 “invented” scriptless frame busting. All the browser vendors have been discussing something like this even before the Clickjacking bubble, and it’s actually useful because:

1. JavaScript-based frame busting is not always reliable, especially on IE (it works fine in Firefox 3, though).
2. JavaScript-based frame busting does not work, quite obviously, if JavaScript is disabled for whatever reason, unless you’re using NoScript.
3. JavaScript-based frame busting can be easily circumvented on IE by loading the targeted page inside an <IFRAME SECURITY=restricted> element. Ironically, yet another Microsoft non-standard extension to HTML, with security purposes this time, makes IE the only contemporary browser where “standard” frame busting is useless by design.

To sum up, there’s always been a well known and accepted server-side protection option which works everywhere except in IE. As far as we know, the newly proposed anti-Clickjacking tag or header (much like the “X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes” suggested as fix #1 in Michal Zalewski’s famous “UI Redressing” post and to ABE’s SUBdocument rules) offers an alternate option which, currently, works only in IE8 RC1. Funny how Microsoft can turn a weakness unique to their browser in yet another non-standardized feature to embrace and extend HTTP overnight! :)
But if a web site owner is skilled and careful enough to implement our brand new header (which again, while I’m writing these lines, is apparently undocumented), he will surely deploy the simple and understood JavaScript frame busting one-liner too, and every browser is equally protected.

Furthermore, the press choose the “Clickjacking” buzzword over the proper “UI Redressing” definition, probably to amplify its hype effect. But historically, the term “Clickjacking” has been invented to designate a Flash-based (or more in general embedding-based), not necessarily cross-domain attack. Does this “anti-Clickjacking” feature actually work against the “original” Clickjacking concept? Nothing suggests it does yet, but we’ll see… 2009-01-28 Update: now we for sure know IE8 RC1 offers no protection against plugin-based Clickjacking, as expected.

However, I do believe that a declarative approach to control subdocument requests is an excellent idea: otherwise I wouldn’t have included the SUB pseudo-method in ABE Rules Specification (pdf). Moreover, as soon as I’ve got some less blurry info (David Ross, I know you’re listening, why don’t you drop me a line?), I’ll be happy to immediately implement a compatible feature in NoScript and lobby Mozilla for inclusion in Firefox 3.1.

That said, the bad news for IE enthusiasts is that they’ve got no magic “out of the box” protection, despite the press releases I quoted. True, it doesn’t require any “browser add-on” (don’t you love how they managed again to avoid mentioning NoScript?), but it comes with an even more strict requirement: all the sites to be protected must already have adopted a new proprietary hack, i.e. something no end-user can verify, let alone enforce (so long for the “consumer-ready” label).
We’ve been preaching about XSS holes and other web programming errors for years, but developers still fall in the same pitfalls over and over again: if the guys in Redmond really believed that web security could be fixed server-side by just educating web authors, why did they eventually bother adopting those client-side anti-XSS filters which NoScript pioneered?

On the other hand, ClearClick protects you against any type of Clickjacking automatically, as soon as you install the NoScript add-on, with no need for web authors to learn and cooperate. ClearClick keeps working even if you allow JavaScript globally and/or disable all the other NoScript protection features, so you’ve got no excuse to dismiss it. Any reason yet not to switch to safer browsing?

Update

Microsoft’s David Ross sent me an email confirming that my “preemptive” analysis about IE8’s approach, intents and limitations was correct. A blog post by Eric Lawrence is on its way, explaining the technical details as an an “authoritative” source, but I guess the only information still missing is the real name of the header :)
About my stated intention of implementing a compatible feature in NoScript and lobbying Mozilla to do the same, he wrote

I think this would be fantastic and it’s a great place to start building some bridges.

I think so too.

Update 2 (2009-01-28)

Mistery unveiled: the header is “X-FRAME-OPTIONS: DENY” (I still prefer “X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes”, but whatever). Now that I’ve got “less blurry details”, NoScript’s compatibility feature is on its way, and I hope Firefox’s is too.

During the past weeks I’ve started a new project called ABE, sponsored by the NLnet Foundation and meant to provide CSRF countermeasures configurable on the client side, the server side or both.

As you probably know, the NoScript browser extension improves web client security by applying a Default Deny policy to JavaScript, Java, Flash and other active content and providing users with an one-click interface to easily whitelist sites they trust for active content execution. It also implements the most effective Cross-Site Scripting (XSS) filters available on the client side, covering Type-0 and Type-1 XSS attacks; ClearClick, the only specific browser countermeasure currently available against ClickJacking/UI redressing attacks, and many other security enhancements, including a limited form of protection against Cross-Site Request Forgery (CSRF) attacks: POST requests from non-whitelisted (unknown or untrusted) sites are stripped out of their payload and turned into idempotent GET requests.

Many of the threats NoScript is currently capable of handling, such as XSS, CSRF or ClickJacking, have one common evil root: lack of proper isolation at the web application level. Since the web has not been originally conceived as an application platform, it misses some key features required for ensuring application security. Actually, it cannot even define what a “web application” is, or declare its boundaries especially if they span across multiple domains, a scenario becoming more common and common in these “mashups” and “social media” days.

The idea behind the Application Boundaries Enforcer (ABE) module is hardening the web application oriented protections already provided by NoScript, by developing a firewall-like component running inside the browser. It will be specialized in defining and guarding the boundaries of each sensitive web application relevant to the user (e.g. webmail, online banking and so on), according to policies defined either by the user himself, or by the web developer/administrator, or by a trusted 3^rd party.

ABE rules, whose syntax is defined in this specification (pdf), are quite simple and intuitive, especially if you ever looked at a firewall policy file:

# This one defines normal application behavior, allowing hyperlinking
# but not cross-site POST requests altering app status
# Additionally, pages can be embedded as subdocuments only by documents from
# the same domain (this prevents ClickJacking/UI redressing attacks)
Site *.somesite.com
Accept POST, SUB from SELF https://secure.somesite.com
Accept GET
Deny

# This one guards logout, which is foolish enough to accept GET and
# therefore we need to guard against trivial CSRF (e.g. via <img>)
Site www.somesite.com/logout
Accept GET POST from SELF
Deny

# This one guards the local network, like LocalRodeo
# LOCAL is a placeholder which matches all the LAN
# subnets (possibly configurable) and localhost
Site LOCAL
Accept from LOCAL
Deny

# This one strips off any authentication data
# (Auth and Cookie headers) from requests outside the
# application domains, like RequestRodeo
Site *.webapp.net
Accept ALL from *.webapp.net
Logout

Living inside the browser, the ABE component can take advantage of its privileged placement for enforcing web application boundaries, because it always knows the real origin of each HTTP request, rather than a possibly missing or forged (even for privacy reasons) HTTP Referer header, and can learn from user’s feedback.
Rules for the most popular web applications will be made downloadable and/or available via automatic updates for opt-in subscribers, and UI front-ends will be provided to edit them manually or through a transparent auto-learning process, while browsing. Additionally, web developers or administrator will be able to declare policies for their own web applications: ABE will honor them, unless they conflict with more restrictive user-defined rules.
As soon as browser support for the Origin HTTP header becomes widespread and reliable, an external version of ABE might be developed as a filtering proxy.

An initial implementation will be released during the 1^st quarter of 2009 as a NoScript module.
I already collected precious feedback from security researchers like Arshan “Anti-Samy” Dabirsiaghi, Ivan Ristic of ModSecurity fame, Sirdarckcat and others.
More opinions and suggestions about rules design and features are very welcome.

Sirdarckcat just pinged me with some more Clickjacking stuff, including his own related work:

• OWASP Presentation (video)
• White Paper
• Effective CSS-based Clickjacking techniques by Sirdarckcat

Regarding protection, if you’re a Firefox/NoScript user you should already know about ClearClick. If you’re not, I feel a bit sorry for you.

Finally NoScript 1.8.2.1 is out, featuring the announced new anti-clickjacking countermeasures enabled by default, independent from IFRAME and plugin content blocking settings.

The most specific and ambitious is called ClearClick: whenever you click or otherwise interact, through your mouse or your keyboard, with an embedded element which is partially obstructed, transparent or otherwise disguised, NoScript prevents the interaction from completing and reveals you the real thing in “clear”. At that point you can evaluate if the click target was actually the intended one, and decide if keeping it locked or unlock it for free interaction. This comes quite handy now that more dangerous usages of clickjacking are being disclosed, such as enabling your microphone or your webcam behind your back to spy you through the interwebs.

As you already know if you read my first clickjacking article, an old and benign clickjacking example is NoScript’s “Install Now” orange button, which overlays the green one on addons.mozilla.org to work-around the installation security warning. If you click it with ClearClick enabled, now you get warned about something sneaky going on.

I do not need to change my button yet, because NoScript 1.8.2.1 ships with ClearClick enabled on untrusted (non whitelisted) parent pages only, while the whitelist status of the embedding is irrelevant. This gives a good balance between effectiveness and usability, since the attacker in a clickjacking attack is always the parent. If you want to get the warning on noscript.net and on the other sites you trust, you need to flag the second checkbox on NoScript Options|Plugins|ClearClick protection on pages… [x] untrusted [x] trusted. I recommend to flag it anyway and report any usability issue, because this feature so far seems quiet and unobtrusive enough to justify my temptation of enabling everywhere (trusted + untrusted) by default on next stable release, but it must get a lot of testing from you first.

Other clickjacking-related features included in this release are:

1. Opaque embedded objects: plugin content and frames are forcibly made opaque and get styled with “overflow: auto” (i.e. get scrollbars if their inner size exceed their viewport) on untrusted pages.
2. Frame Break Emulation: if a framed page which is not allowed to run JavaScript contains a “frame busting” script similar to
   <script>if (top != self) top.location = location</script>

   , the intention of the page author is honored by NoScript, i.e. the page replaces the topmost document. You can control this feature toggling the noscript.emulateFrameBreak about:config preference.

3. Some usability and effectiveness improvements in frame management, making the Forbid IFRAMEs option more suitable for general usage.

I hope to find some time during this week to write another post, diving through the technical details behind my ClearClick implementation: a fairy tale about a very simple and hopeful idea (unconventional <canvas> usage) fighting against an army of quirks and mundane details. In the meanwhile, many thanks to Sirdarckcat, RSnake, Michal Zalewski and Matt Mastracci for discussion, testing and inspiration.

As I hinted in my original clickjacking article and confirmed in my follow-up about protecting other browsers from clickjacking, specific anti-clickjacking countermeasures are included in latest NoScript development builds, enabled by default, and completely independent from frame blocking.

Specifically, since 1.8.1.7 (released past Friday), embedded objects of any kind are forcibly made opaque if placed on a non-whitelisted page, giving user a clear view on what he’s about to click.
A further protection layer, automatically disabling any user interaction with partially obstructed documents (similar in concept to Zalewski’s preferred proposal), will go in a stable release by the end of this week, but current development builds are already safe and good enough for general consumption, so I recommend upgrading now (update) is available in NoScript 1.8.2 and above.

Starting this fresh development line, rather than sitting on the serendipity of old NoScript features being able to prevent known forms of clickjacking, proved to be a very wise thing to do.
In facts, both RSnake and Ronald during the last two days found frame blocking work-arounds. RSnake in particular, being a NoScript user himself, has been so kind to do responsible disclosure, giving me also a lot of constructive feedback about the alternate mitigation ideas I was developing.

I must be grateful to Ronald as well, because he — even if in a less cooperative way — underlined a conceptual weakness in IFRAME blocking (since OBJECTs can behave just like IFRAMEs, they should be blocked according to the very same criteria), but I have to rectify this statement from his public disclosure post:

The latest version of NoScript allows it’s users to block iframes in order to protect themselves from “Clickjacking”.

NoScript has been capable of blocking IFRAMEs for a long time: this feature had been introduced mainly to make Gareth Heyes happy, more than one year ago. As often observed with NoScript, an old feature happens to be effective against new threats.
Unfortunately, bugs happen too and IFRAME blocking not being applied to all the frame-like elements is what I do consider a bug. This one will be fixed in the automatic stable update you’re going to receive in a few days, but in the meanwhile is already fixed; you can enjoy the new specific clickjacking protection, no matter if you block frames or not, by simply upgrading to NoScript 1.8.1.8 or above.

Update Oct 2^nd, afternoon

The frame/object bug has already been fixed in 1.8.1.9, one more reason to upgrade.

Update Oct 7^th

NoScript 1.8.2 is finally out, featuring the brand new exclusive ClearClick technology against Clickjacking. Upgrade now!