Looks like Clickjacking is the web-security buzzword of the week (month?), since Robert “RSnake” Hansen and Jeremiah Grossman decided to cancel their OWASP talk, drawing an aura of mystery around the whole issue and its magnitudo.
Nevertheless some info and speculations have been percolating, and even if the precise details of the attacks proposed by those two researchers are still embargoed, especially because of the serious and not necessarily obvious implications worrying Adobe, a certain awareness about the general technique and the possible countermeasures does circulate now. In Jeremiah’s and RSnake’s words:
Think of any button on any Web site, internal or external, that you can get to appear between the browser walls, wire transfers on banks, Digg buttons, CPC advertising banners, Netflix queue, etc. The list is virtually endless and these are relatively harmless examples. Next, consider that an attack can invisibly hover these buttons below the usersâ€™ mouse, so that when they click on something they visually see, they actually are clicking on something the attacker wants them to. […]
Say you have a home wireless router that you had authenticated prior to going to a [malicious] web site. [The web site] could place a tag under your mouse that frames in a single button an order to the router to, for example, delete all firewall rules.
In other words, the attack is thrown by a malicious web page embedding objects, possibly from a different site, such as framed documents or plugin content (Flash, Silverlight, Java…) which may lead to unwanted results if clicked by the current user (e.g. a “Delete all messages” button in your webmail or an advertisement banner in a click fraud scheme). Using DHTML, and especially CSS, the attacker can disguise or hide the click target in several ways which go completely undetected by the user, who’s easily tricked into clicking it in a more or less blind way.
Nevertheless, as RSnake puts it,
[…] the best defense against clickjacking attacks is to use Firefox with the NoScript add-on installed. Users running that combination will be safe, said Hansen, against â€œa very good chunk of the issues, 99.99 percent at this point.â€
A final recommendation is reading this Michal Zalewski’s contribution, which covers the IFRAME case only but is very generous with mitigation proposals, both for web developers and browser vendors: by the way, his browser fix proposal #4 is almost identical to current NoScript’s Forbid <IFRAME> option, and simpler variants of proposal #3 are being explored as default features in NoScript development builds since version 22.214.171.124.