UI redress attacks (aka Clickjacking)

Recently there has been quite a bit of noise about attacks involving a technique dubbed ‘Clickjacking’. The tale starts back in September when a talk planned for the OWASP conference was pulled at the last minute, due to concerns about disclosing details of the attack [1, 2].

The combination of the cancelled talk and scant attack details was sufficient to pique the interest of many, and speculation over the last few weeks about how the attack worked has been rife [3,4,5]. Earlier this week, the cat escaped its bag – a proof of concept demonstration of the attack was released [6]. Since then, the original researchers have published full details [7,8].

So, exactly what is clickjacking? And what can you do to prevent being hit by it?

Basically the attack revolves around the ability to control the links the user visits when on a web page. An attacker is able to construct a malicious web page and mislead the victim into clicking on certain (visible) links/buttons, whereas in reality, they are actually clicking on other links/buttons (not necessarily visible to them). So the user clicks on something they can see, but the page is constructed such that another link or button is “hidden” (or partially obfuscated) beneath the mouse, and this hijacks the click.

Javascript is not required for this sort of attack to work. It can help, but it is not essential. There are several ways in which content can be loaded and positioned within a web page (CSS overlay techniques for example, which are common). Attackers can exploit these techniques to construct a page where what the user sees and clicks on, does not reflect what action their click actually “performs”.

As an example, one of the proof of concepts released shows an attack against the Adobe FlashPlayer settings manager [9]. The video available from the PoC post clearly illustrates how the attack works [6]. Note the update to the settings manager page to resolve the issue through the addition of ‘frame busting’ Javascript:

if (top!=self){
top.location.href=self.location.href;
}

In terms of what you can do to protect yourself, options are limited without severely hampering your browsing experience (disabling plug-ins for example). The latest version of NoScript [10] does include additional protection (dubbed ‘ClearClick’) which is designed to specifically protect against these attacks [11]. Enabling this plug-in and then browsing another proof of concept [12] demonstrates NoScript in action:

Notice how the warning message includes an image of the actual UI hovering beneath the victim’s mouse. Clicking on this image enables you to toggle it with what the victim actually sees.

Pretty neat. Readers should be prepared for some degree of false alarms when using this (or similar) features. Not because of any deficiency in the products, but because of the nature of what they are checking for. (Think about some of today’s popular sites that use UI redressing techniques to deliver the slick web applications we have grown used to.)

NoScript users will also be pleased to hear that with the latest version even if Javascript is disabled for a particular domain, frame busting code is still honoured (thanks to the new ‘Frame Break Emulation’ feature).

Personally I favour the term ‘UI redress’ to describe this type of attack [13], but Clickjacking is certainly more catchy, and has caught the headlines.