Wednesday, December 23, 2009

5 ways to prevent clickjacking on your website (and why they suck)

Clickjacking attack is a very nasty attack. The most common form of it is when an attacker creates a webpage and tricks the visitor to click somewhere (on a link, button, image). Attacker in the code of his website includes a victim website (like Facebook, your webmail, amazon) that is cleverly hidden from the user and placed so that a user actually clicks on a victim website. Citing the example from OWASP page on clickjacking:

For example, imagine an attacker who builds a web site that has a button on it that says "click here for a free iPod". However, on top of that web page, the attacker has loaded an iframe with your mail account, and lined up exactly the "delete all messages" button directly on top of the "free iPod" button. The victim tries to click on the "free iPod" button but instead actually clicked on the invisible "delete all messages" button. In essence, the attacker has "hijacked" the user's click, hence the name "Clickjacking".
The problem with clickjacking attack is that it is extremely difficult to prevent. Unlike other popular vulnerabilities like CSRF, XSS, SQL injection, this one is based on a functionality that is widely used in the web nowadays - frames (I'm skipping the case of plugin-based-clickjacking for clarity here). Frames allow you to nest one webpage or widget in another page - this is now used for login pages, commenting, previewing content in CMSes, for JavaScript interactions and a million other things.

Browsers nowadays use same origin policy to protect your data if you're framing or being framed from another domain (this prevents JavaScripts from talking to each other and accesing documents across the domain boundary). But JavaScript is not required for a clickjacking attack - CSS is enough. In the simplest form (e.g. used in recent Facebook users attack), you're just using a small <iframe>, and position it absolutely. The rest is just social engineering.

Our users have a few options to protect themselves. So maybe 1% of them will be "protected". But what can we - web developers do to prevent the clickjacking on our sites? Sadly, not much, but here's the list:

Monday, December 21, 2009

New Facebook clickjacking attack in the wild - fb.59.to

There's a malicious website set up at http://fb.59.to that tries to trick users into a clickjacking attack that shares the link on victims' Facebook accounts.


Some Facebook users today saw a comment looking like this (new pix!):







Clicking on the comment that links to

http://www.facebook.com/l.php?u=http%253A%252F%252Ffb.59.to%252F%253F4ff11a526ae73e9f170bbe6702ebb93c&h=..somehash...&ref=nf

redirects users to http://fb.59.to web page.

On this page they are given a fake Turing test that tricks them into clicking a "blue button" which is their clickjacked Facebook page positioned at adding a new comment ("Share" button). The whole web page looks like this (clickjacked area is marked green):



In page source we can see that there is a IFRAME element:

<iframe frameborder=0 scrolling=no height=25 width=100
src="2.php?u=http://fb.59.to/?...somehash...."
></iframe><span style=background-color:yellow;><font 
style=font-size:13 ; color=white>

The target URL (2.php) has another IFRAME which in turn has yet another one with the target page being

<div style="left:-90px;top:-386px;position:absolute;"
<iframe height=400 width=250  src="http://www.facebook.com/sharer.php?u=http://fb.59.to/?hash" 
frameborder=0  scrolling=no> </iframe>
</div> 

Clicking on the button shares the malicious link on Facebook.

The page has a meta-redirect set up to a Youtube movie launching  in 12 seconds so a users might get the impression that the movie launched because they successfully passed the Turing test.

Multiple iframes are probably set up to trick clickjacking protections within browsers. A quick look tells that currently Firefox and Chrome are vulnerable to the attack, IE and Opera being safe, although that requires a bit more time to investigate.

Update: The attack does not work in IE and Opera only because of incorrect HTML used in one of the pages in this malicious site. Doing a simple fix in HTML makes both mentioned browsers also vulnerable to the attack.

Thanks go to Grzegorz Ciborowski and Pawel Czernikowski for detecting the attack.