I heard of clickjacking a couple of weeks back when the media blast started. At that time a had a very vague idea what it was and just recently I saw some POCs coming out to show how it works in practice.

P4144556

Clickjacking, if I may categorize it, falls into the category of GUI attacks. I associate the clickjacking attack with the focus stealing attack which allows attackers to steal any file from the disk as long as they trick the victim to type enough characters. Ok, this is not a razor-sharp exploit but it is an exploit nevertheless.

In essence, the clickjacking technique allows attackers to trick the victim to click on areas of a disguised HTML elements such as an IFRAME preloaded with let’s say your Facebook account information. If nothing else, clickjacking is the killer of most anti-CSRF techniques.

I haven’t been thinking about clickjacking at all. I mean the attack is quite obvious and the potentials for damage are there. However, this morning when woke up, an interesting question started to circulate in my head. What is Adobe’s deal? After all, Adobe are the ones who asked Jeremiah and rsnake to cancel their OWASP presentation. The answer came quite quickly and naturally.

The simple truth is that Adobe are worried about the clickjacking technique because Flash’s current and even future and a lot more enhanced security model relies on user interactions, i.e. clicks performed by the user. Therefore, today attackers can trick the user to allow the microphone to survey the sound in the room where the victim’s equipment is located. They can use clickjacking for that! But there is more.

If you have been following the development of the Flash platform, you are probably aware that Flash will soon become practically the most powerful web tool out there. Seriously, Adobe are revolutionizing the way we interact with the Web. Not only Flash will support a primitive P2P streaming protocol (I need to think of something malicious to do with that…), but they will also allow users to open and save files from and to their local disk. The only catch is that this feature is available via the FileReference class which contains methods that cannot be accessed directly. Instead, the developer needs to bind them to onclick events.

IMHO I do not think that this security model is bulletproof. The potentials for abuse are obvious, and since clicks are the driving force of future Flash’s security model, then clickjacking is what it comes to mind if you want to abuse them. Perhaps, in the future we might be able to connect to TCP sockets as long as the user clicks?

In conclusion, clickjacking is not a killer problem and it does not break the web, well not entirely. However the clickjacking problem is hard to solve. IMHO, I believe that it is even harder to solve then any overflow you may have to deal with. Why? Because we are dealing with user interaction and graphic design related problems. The solution has to be so clean that it doesn’t break half of the Web.