ClickJacking.  One of the newest and most talked about, yet at the same time one of the most secretive new buzz words in Internet Security.  Clickjacking is actually a rebrand of what was originally called "UI Redress".  I guess ClickJacking was considered a sexier term.

What is it? 

Don't get me wrong, the concept of ClickJacking is not new.  The term has been floating around for about a year now.  Jeremiah Grossman and Robert "RSnake" Hansen were supposed to give a talk about it at the OWASP NYC Appsec conference, but were asked by people at Adobe to not give the talk as the vulnerability affects one of their products.

Essentially what ClickJacking entails is using iframes and web page layers in DHTML such that you overlay a potentially malicious button (for example) on top of an existing legitimate web page button such that when a user clicks it they believe they are clicking the legitimate button instead of your malicious overlay.  This all happens transparently to the user.  At this point the users click on the button has been "ClickJacked"

Since ClickJacking does not require Javascript (as so many of today's other web based attacks do) using plugins like NoScript will not provide any relief.  In Firefox you can turn off iframes, but this is a global setting, not a per site setting.  So, if you turn off iframes in your Firefox config you've now disabled them for every web site, and there is no telling what you could break on how a web site is supposed to render if you do this. 

In case you are interested there is a fairly detailed write up here that defines the problem and why it is difficult to fix.  It also outlines some potential solutions, all of which have their positives and negatives.  It's fairly wordy so if you don't generally like to have to hack through the technical weeds of a problem you may not find it interesting.

ClickJacking is an interesting problem to address because right now so little is known on a wide scale about what the issue is and how to identify whether or not your application is being compromised.  Additionally, there are virtually no tools to assist web site designers to protect themselves.  I am sure that will change as more is learned about this type of attack, but typically those tools are developed well after the attack vector is being actively exploited.  It's too late then.  That's like installing the burglar alarm after your house has already been robbed.

Although it is nice that Adobe wants details withheld until they can patch the vulnerability within their own application, that does nothing for the other web site application developers who will be playing a serious game of catch up after the fact...