Clickjacking

Good Q&A on clickjacking:

In plain English, clickjacking lets hackers and scammers hide malicious stuff under the cover of the content on a legitimate site. You know what happens when a carjacker takes a car? Well, clickjacking is like that, except that the click is the car.

“Clickjacking” is a stunningly sexy name, but the vulnerability is really just a variant of cross-site scripting. We don’t know how bad it really is, because the details are still being withheld. But the name alone is causing dread.

EDITED TO ADD (10/13): More details.

Tags: browsers, cross-site scripting, web

Posted on October 6, 2008 at 1:45 PM • 27 Comments

Comments

Bill Zeller • October 6, 2008 2:14 PM

I’d say Clickjacking is more a varient of CSRF attacks, since XSS implies some type of code injection (although both names could be much more clear).

Braden • October 6, 2008 2:17 PM

I wouldn’t agree that it’s just a variant of XSS–it requires no foreign code on the target site. Heck, I’d say it’s more than a CSRF variant, because even if you’re checking one-time tokens, you’re still vulnerable.

The noscript guy’s description of clickjacking is the most cogent I’ve read yet.

Braden • October 6, 2008 2:18 PM

No links, huh?

http://hackademix.net/2008/09/27/clickjacking-and-noscript/

Mark • October 6, 2008 2:26 PM

Based on the rumors and innuendo floating around the net. It appears this would be rather useful in bypassing traditional CSRF protections such as nonces (Page tokens). Could be interesting ….

Robert • October 6, 2008 4:22 PM

Here is an interview with jeremiah grossman published this morning providing more details.

http://www.cgisecurity.org/2008/10/interview-jerem.html

jnarvey • October 6, 2008 4:30 PM

Stunningly sexy, eh? I thought the only security threats that qualified for that description were the lovely Russian spies in those James Bond movies of the Roger Moore era. We live in changed times.

Knowler Longcloak • October 6, 2008 4:34 PM

So why does this surprise people that this is an attack vector?

It seems to me, reading the limited descriptions that it is similar to what I did back in the 1990’s when I programmed a series of web pages to act like a PowerPoint presentation. (You clicked anywhere on the page to advance to the next slide.) All it took was an absolutely positioned, hyper linked, graphic at an opacity of about 0.3% (1 of 255) with an astronomically high z-index to cover the section of the webpage you wanted to go to the next link. (It wouldn’t work with an absolutely transparent graphic in Netscape 4.0.)

It can be delivered using XSS to any vulnerable website to do anything that the browser is authorized for a user click (popup windows, go to another identical looking website to enter information, etc.). It just remains how many different ways that it can be delivered. It also does not need to be script based to work. It could all be done in plain HTML and stylesheets.

I admit that I did not consider it an attack vector until I read what little details were released, but it seems logical to me.

Davi Ottenheimer • October 6, 2008 6:13 PM

It’s not new. It’s just being described more accurately now, and marketed better by those trying to make money from scaring you into buying their services.

James • October 6, 2008 6:38 PM

lcamtuf’s post in whatwg ( http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016284.html ) describes “UI redress vulnerabilities”.

You can see how, when one site is able to relabel another site’s buttons, or make the action they perform look completely different (by changing the surrounding context), this would be another way of saying “clickjacking”.

I long for the good old days of Telnet (ok, SSH), where one site was one session, and sites didn’t feel the need to embed and crosslink themselves into our current house-of-cards situation…

Jeroen • October 7, 2008 1:58 AM

You know what happens when a
carjacker takes a car? Well, clickjacking
is like that, except that the click is the
car.

So someone shows up at your office, puts a gun to your head, and demands you hand over the keys of your … click?

evilhackerdude • October 7, 2008 5:42 AM

I don’t know whether it qualifies, but I commited a little experiment when I first read about clickjacking:

1) Put iframe with target URL as src attribute (facebook.com) into container div

2) Reposition iframe to expose a certain part of the website (Logout button) and resize the container div to match (Logout button size)

3) Create a fake input element (link, button, text input) and position the iframe on top of it (via absolute positioning)

4) Adjust z-index (1000) and opacity (0.01) of iframe

The user is then being tricked into clicking the fake input element (Submit button as part of a form). In reality the input element in the iframe is being clicked. The user can not see this without looking at the source code because the iframe is invisible.

In case of Facebook and other eternal-login-cookie websites (Google) it’s possible to trick the user into clicking whatever input element the attacker desires. The only limitation is that the input element has to be reached via an absolute and persitant URL (facebook logout button, Google My Account page, …).

Clive Robinson • October 7, 2008 5:47 AM

It’s a long time since I used javascript in anger but if I remember correctly there may be a partial solution to this that servers could use.

One of the problems with javascript used to be the scope of functions.

Basically if the functions where not in the root window then you had to jump through all sorts of hoops to make them visable to decendent windows.

It may be possible for a sites programer to write the script for their controls to check and see if the sites root window is actually the root window on the browser. If not then flag up a dialog box asking for confirmation or warning the user etc.

I shall have to have a think on it and a little experimentation…

Arkh • October 7, 2008 8:31 AM

@evilhackerdude : I think you’re on something. Maybe not for facebook or google, but a lot of other websites use GET parameters too much.
And with this kind of trick, the simple protection methods (referrer check, form tokens etc.) can’t be used.
Only asking for a double-check would start to complexify the attack, but users don’t like this kind of things.

It may sign the comeback of deframing scripts to be sure that your website isn’t in a frame.

Maneesh • October 7, 2008 10:32 AM

How is clickjaking fundamentally different form Cross Site Request Forgery? Isnt it the same as some of you have pointed out? In CSRF the attack is generally carried out without any user action- as it happens when embedded in an img or script tags . In Clickjacking howerver, it looks like, users need to ‘click’ to trigger the attack and hence termed as ‘click’jacking. But fundamentally are they not the same?

christopher • October 7, 2008 2:18 PM

could the computerworld site have any more ads on it? sheesh.

Sleep Deprivation Ninja • October 7, 2008 2:39 PM

GET is a real problem. The original exploit I remember of this type is simply adding an image reference on a page like [img src=’http://victimsite.com?param=value’ /]
then the query loads on page load, using the user’s credentials for that domain. If the site relies on GET params for important transactions, this is a big problem.

Luckily, nobody who has any web dev sense does this. But there are plenty of devs out there who don’t think about those things.

The Operator • October 7, 2008 2:55 PM

The attack vector is as old as Javascript itself (DOM + window.location manipulation), however, browsers’ AJAX implementations make it that much easier.

Consider:

(1) User arrives at malicious site (or a site which a malicious user has embedded code upon)

(2) Malicious site loads Javascript which includes a sniffer (capable of passing information – i.e. usernames and passwords – from sites the user visits back to the attacker via image file GET’s on a server the attacker monitors) and a clicker component which may retrieve instructions from the attacker or execute a predefined set of actions

(3) ???

(4) PROFIT

John O'Neill • October 7, 2008 4:03 PM

Is there a specific software or hardware solution anyone here would recommend as conducive to redcing the possibility of a user being clickjacked?

This is worring stuff. I have little sympathy for someone being scammed when they visit suspect sites without due caution but the possibility of being clickjacked while on a reputable site you visit frequently is hard to comprehend and it would appear to me, hard to avoid.

John
http://www.backupanytime.com/background.htm

Braden • October 7, 2008 4:40 PM

John, as the article I linked above says, Firefox with NoScript ( http://noscript.net ) will stop almost all clickjacking attacks on untrusted sites. However, for any site on which you enable rich content, you’re trusting them to prevent malicious script injection from hostile users.

Sleep deprivation ninja, POST doesn’t prevent CSRF. It makes it more difficult and Javascript-dependent (attackers need to create a POST form and submit it with Javascript), but to really fix CSRF, web developers need to be using one-time tokens for every dangerous form submission.

Maneesh, the alarm over clickjacking is that it bypasses one-time token protection–your browser acts as though you really have loaded up a trusted site and confirmed your intent. Web developers can do little to protect themselves until browsers make this cross-site interaction obvious to users.

Weasel5i2 • October 8, 2008 9:04 AM

My theory: Legitimate page is displayed. Malicious page is a full-window overlay, invisible, set to TOP z-index, and has imagemapping or something similar to put the invisible overlaid links on top of the real links on the legitimate page below, and since the overlay is invisible, the user has no clue!

This could probably be done with CSS too..

Eeeeevil!!

Weasel5i2 • October 8, 2008 9:09 AM

Also, spammers on MySpace have been doing this for a long time now (at least 1 year).. You visit a spammy profile and all of the usually-normal MySpace links on the page are hijacked to send you to the spammer’s dating/pix/crap website.. I’ve encountered spam profiles where even the “Report Abuse” link was hijacked!!

-Weasel

Braden • October 8, 2008 12:20 PM

Full details: http://ha.ckers.org/blog/20081007/clickjacking-details/

Clive Robinson • October 9, 2008 9:26 AM

Looks like “Great minds think alike” 😉

I posted (October 7, 2008 5:47 AM),

“It’s a long time since I used javascript in anger but if I remember correctly there may be a partial solution to this that servers could use…

…I shall have to have a think on it and a little experimentation.”

And in the post to ha.ckers.org they say,

“Turning off JavaScript also neuters one of the only practical web based defenses against the attack which is the use of frame busting code.
~
~
Frame busting code is the best defense if you run web-servers, if it works (and in our tests it doesn’t always work).”

Ah well at least they tried which is more than I got around to since the post.

Maneesh • October 9, 2008 11:56 AM

Branden, You said one-time token are ineffective. Is it because the form (for e.g.) itself gets loaded in the malicious site and so does the one-time token and your clicks are clickjacked to say submit the form? Is this the case?

Aronzak • October 11, 2008 7:10 PM

Looks like ClearClick works for me. I think that this will blow over in a short while.

http://aronzak.wordpress.com/2008/10/12/noscript-preventing-clickjacking/

Braden • October 14, 2008 2:19 PM

That’s exactly right, Maneesh. Malicious sites can’t directly read one-time tokens because of cross-site restrictions, but they can trick users into submitting the token-protected forms themselves.

Hugh • October 24, 2008 12:52 PM

Now we can not trust url address line as a safe check, because in clikjacking url displayed in a status bar can be forged

Clickjacking

Comments

Leave a comment Cancel reply