Clickjacking allows someone to place an invisible link/button below your mouse as you browse a regular page. You think you’re clicking on a regular link, but really you are clicking someplace the attacker controls that’s hidden from you. Why is this important? Because it allows the attacker to force you to interact with something without your knowledge on a page other than the one you’ve been looking at. For example, they can hide a Flash application that follows your mouse around, and when you go to click a link it starts recording audio off your microphone. We have protections in browsers to prevent someone from automatically initiating certain actions. Also, many websites rely on you manually pressing buttons for actions like transferring large sums of money out of your bank account.

There are two sides to look at this exploitation- user and website owner. As a user, if you visit a malicious site (either a bad guy site, or a regular site that’s been hit with cross site scripting), the attacker can force you to take a very large range of actions. Anytime you click something, the attacker can redirect that click to the destination of their choice in the context of you as a user. That’s the important part here- it’s like cross site request forgery (really, an enhancement of it) that not only gets you to click, but to execute actions as yourself. That’s why they can get you to approve Flash applications you might not normally allow, or to perform actions on other sites in the background. As with CSRF, if you are logged in someplace the attacker can now do whatever the heck they want as long as they know the XY coordinates of what they want you to click.

As a website owner, clickjacking destroys yet more browser trust. When designing web applications (which used to be my job) we often rely on site elements that require manual mouse clicks to submit forms and such. As Robert (Rsnake) explains in his post, with clickjacking an attacker can circumvent nonces (a random code added to every form so the website knows you clicked submit from that page, and didn’t just try to submit the form without visiting the page, a common attack technique).

Clickjacking can be used to do a lot of different things- launching Flash or CSRF are only the tip of the iceberg.

It relies heavily on iFrames, which are so pervasive we can’t just rip them out. Sure, I turn them off in my browser, but the economics prevent us from doing that on a wide scale (especially since all the advertisers- e.g. Google/Yahoo/MS, will likely fight it).

Clickjacking is very difficult to eliminate, although we can reduce its risk under certain circumstances. Because it doesn’t even rely on Javascript and works with CSS/DHTML, it will take a lot of time, effort, and thought to eliminate.

If that sounded scary, have a look at a video showing one application of the exploit:

If you want to study that further, you can actually run it through it’s paces here.

So, what can be done about this? First of all, it’s worth realising that while it’s a powerful threat, the risk of it happening isn’t that high at the moment. Vendors have started recognising the threat and coming up with solutions for dealing with it. Adobe has come up with a workaround and NoScript has released ClearClick to help address it. It’s only a matter of time before this is quashed too (won’t be easy though)

I recall a mention on ITV about a local company providing unlocking services, so headed down to iPhone Unlock UK.com, company who offer iPhone unlocking services. Unlocking costs £39.99 for the DIY unlocking package or £69.99 for a technician to do it for you. Their website promises great service. The charge you pay covers a complete solution “for the lifetime of your iPhone purchases”. They provide support, free updates to the software and regular communication. That’s nice actually, the last thing you want is to turn your iPhone into an expensive paperweight.

• Cookie Poisoning
• Hidden Field Manipulation
• Parameter Tampering
• Buffer Overflow
• Cross-Site Scripting
• Backdoor and Debug Options
• Forecful Browsing
• HTTP Response Splitting
• Stealth Commanding
• 3rd Party Misconfiguration
• Known Vulnerabilities
• XML & Web Services Vulnerabilities

The white paper also goes into some advice on how to code defensively and avoid these issues, namely:

• Never trust any information that comes from the client, and never assume anything about it
• It is always easier to secure simple login than complex logic

Although a bit basic, it makes interesting reading. Read the whole? white paper? here.

It seems like the? main reason nothing’s been found yet is simply that there aren’t too many people who have? access to the device. First of all, it costs a bomb and secondly it’s only available in the U.S. ? If it were more widely available, someone would have already installed Linux on it. So, grab a chair, settle in to watch and in the meantime, keep an eye on the iPhone cracking Wiki, lots to learn there.

Here’s one of the scenarios he painted:

There are all sorts of automated scripts out there that search for vulnerable PHP applications, exploit them when found, and then automatically download a set of phishing HTML files and images that make John’s Awesome Blog suddenly look like the Bank of America’s login page. This also happens with ASP and Perl applications too, as well as those written in other languages, but today PHP is far more popular a target. That website owner, John, might be held responsible too if there weren’t dozens of these incidents each day.

Pretty scary huh? Well it’s worth paying head to the article so check it out!