Tuesday, September 30th, 2008

This Week in HTML 5: Clickjacking

Category: HTML, Standards

Mark Pilgrim, in his latest episode on This Week in HTML 5, got into an interesting topic indeed: clickjacking.

The big news this week is the disclosure of a vulnerability that researchers have dubbed “clickjacking.” To understand it, start with Giorgio Maone’s post, Clickjacking and NoScript. Giorgio is the author of the popular NoScript extension for Firefox. In its default configuration, NoScript protects against this vulnerability on most sites in most situations; you can configure it to defeat the attack entirely, but only at the cost of usability and functionality.

Of course, most web users do not run Firefox, and fewer still run NoScript, so web developers still need to be aware of it. Michal Zalewski’s post, Dealing with UI redress vulnerabilities inherent to the current web, addresses some possible workarounds:

  1. Using Javascript hacks to detect that window.top != window to inhibit rendering, or override window.top.location. These mechanisms work only if Javascript is enabled, however, and are not guaranteed to be reliable or future-safe. If the check is carried on every UI click, performance penalties apply, too. Not to mention, the extra complexity is just counterintuitive and weird.
  2. Requiring non-trivial reauthentication (captcha, password reentry) on all UI actions with any potential for abuse. Although this is acceptable for certain critical operations, doing so every time a person adds Bob as a friend on a social networking site, or deletes a single mail in a webmail system, is very impractical.

Worried yet? Now let’s turn to the question of what browser vendors can do to mitigate the vulnerability. Michal offers several proposals. It is important to realize that none of these proposals have been implemented yet, so don’t go rushing off to your text editor and expecting them to do something useful.

A few suggestions were discussed and one “moves us down a slippery slope towards site security policies for IFRAMEs and embedded content, similar to the Flash security model that allows trusted sites to access cross-domain resources. In practice, Flash crossdomain.xml files have a number of problems, and such an approach would still only cover a fraction of the possible use cases.”

Posted by Dion Almaer at 7:47 am

3.5 rating from 11 votes


Comments feed TrackBack URI

Wow, I saw this on /. last week, but I hadn’t realized how bad the attack is with Javascript enabled. Thanks for including Giorgio’s explanation.

Comment by bander — September 30, 2008

on this topic of flash being “so bad” with its immature security model — this is such a tired, over-used argument. The 9.0.124 version of the player has addressed most (but certainly not all) of the major concerns with the security model. While providing a flexible but powerful model for flash communication authorization, indeed it’s also been leveraged for other communication (including Silverlight), and it paves a way for the pattern that other similar approaches can take. In addition, since Adobe’s been at this part of the game for a couple of years now, there’s a good chance that they’re not just “immature” at it like most people seem to want to believe.
Man Adobe bashing (especially without much backing) really gets old after awhile.

Comment by shadedecho — October 2, 2008

Leave a comment

You must be logged in to post a comment.