

CSS-Only Clickjacking - flexterra
http://jsfiddle.net/gcollazo/UMyEm/embedded/result/

======
simonw
"This seems like a real security threat and I haven't found a foolproof way of
detecting it. Is there a way of protecting against this kind of attack?"

No. If you're going to provide clickable widgets that can be embedded in other
people's sites, there is no technical method for preventing clickjacking.

Even if it was impossible to hide the element (pointer-events: none is one
method, another is to place the Like button itself on a div with an opacity of
0.001) it could still be attacked by tricking people to click repeatedly in a
certain area and then displaying the button. "Click here five times as fast as
you can to win a prize" kind of thing.

The developers of the Facebook Like / Twitter Follow buttons know this, but
they decided that the trade-off was worth the risk. There are also statistical
counter-measures they can take behind the scenes (machine learning algorithms
for identifying large numbers of potentially fraudulent Likes for example).

~~~
padolsey
> there is no technical method for preventing clickjacking

I think there is. Most of these widgets are embedded using SCRIPTs which have
access to the parent page's DOM structure. For Twitter/Facebook they can
basically access anything on your page. This means, they can do a check for
`pointer-event:none` (computed CSS value) on the element above the widget (get
that using `document.elementFromPoint`).

EDIT: After some investigation: elementFromPoint doesn't work on elements with
pointer-events:none, it seems. That sucks. It may still be possible to
circumvent these attacks. For example, when the widget receives a mouseenter
event, it could place itself at the end of the document tree in the parent
page and ensure it has the highest possible z-index. I'm sure there are other
viable options too...

~~~
darklajid
I'm not following.

You suggest that these obnoxious buttons should start behaving even more
annoying by peeking around the side and potentially rearranging/changing
themselves?

First, I don't believe that an arm's race makes sense. There are too many ways
to trick someone into clicking a thing. Second: Please... Like buttons are
already as lovely as blink tags on a Geocities page. They don't need to be
'improved' like that.

------
franciscoapinto
This again?

Ah. Good old noscript.

<http://i.imgur.com/Cb17T.png>

~~~
Zarel
Hmm.

I don't know why `pointer-events:none` is being made a big deal of. In the
past, it was easy enough just to put the Like button on top, and set its
opacity to 0; all `pointer-events:none` does is make that easier.

More relevantly, we used clickjacking back in the day to do things like have
custom Upload buttons (since it wasn't possible to finely style an `<input
type="file">`). Does NoScript warn against that? (and should it?)

------
beggi
This is possible in IE as well with this code:

    
    
      .clickjack_overlay {
         filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='white.png', sizingMethod='scale');
         background:none !important;
      }

------
turshija
Well, for that (and similar facebook-like clickjacking) Facebook implemented
some kind of "protection". If there are too many unlikes shortly after Like
button is pressed, new users that click on Like button will be presented with
confirmation, something like "Are you sure you want to like this page?"

------
bgarbiak
So, the news here is that's "CSS only". Well, I hope no one will ask for
_pointer-events_ removal because of this. The feature is very useful exactly
because it doesn't require JS (example: transparent tooltips). And for
hijackers it makes almost no difference - to include "Like" kind of button
they need a script anyway.

------
juddlyon
Weird, had to look it up. Mozilla Developer Network entry on pointer-events:
<https://developer.mozilla.org/en/CSS/pointer-events>

------
rabidsnail
"pointer-events: none;"

WTF? When did that get implemented?

~~~
chime
The click-jacking ability has been known for over a year now:
[http://robertnyman.com/2010/03/22/css-pointer-events-to-
allo...](http://robertnyman.com/2010/03/22/css-pointer-events-to-allow-clicks-
on-underlying-elements/)

------
Zirro
NoScript catches them both. It needs to be recognized as much more than just a
JavaScript-blocker.

~~~
Steuard
And just to be clear, NoScript catches these even when it is set to allow
JavaScript by default! Running NoScript in "Allow Scripts Globally" mode
breaks almost no sites and _still_ protects you against lots of nasty attacks.

------
Imagenuity
This is why I always use a Chrome incognito window for everything I don't
completely trust. No big deal in this case because I'm not logged in to
anything when browsing. If a site prompts me to log in to Facebook or twitter
(as in this case), I know something is fishy. Is it a bit more of a hassle?
Yes, but not as bad by an order of magnitude of getting an account hijacked.
My biggest friend is right-click and "Open link in incognito window".

~~~
themonk
Command+Shift+N

~~~
Imagenuity
\--incognito (add this to the command line after Chrome)

------
pioul
How is that different from putting an "opacity: 0" like button above a link
(in that case)?

------
drewmclellan
Theoretically, adding the following to your browser's user stylesheet should
defeat this:

    
    
        a { pointer-events: auto !important; }
    

The !important keyword adds weight to the rule, which trumps origin,
specificity and sort-order in the CSS cascade.

A quick test in Safari/Mac confirms that works for this particular case.

------
PStamatiou
Time to make a chrome extension that injects code to override this..

------
TazeTSchnitzel
There isn't a way of protecting against this attack, unless these buttons
can't be embedded in web pages.

Well, that, or use Flash.

~~~
pacmon
@taze There is a way. It's called noscript. Does a terrific job of staying on
top of issues like this.

Also because of this example I went one step further and used AdBlock to block
any iframe with a facebook url.

@general The facebook button (at least in firefox) doesn't change to the hand
icon when hovering over the link. So, fail. I wouldn't click a link where the
cursor didn't change. Mostly, because when it doesn't change I immediately
become suspicious.

~~~
darklajid
As someone who's lazy with AdBlock (subscribe, forget): Can you share that
rule?

~~~
pacmon
Hey. Sorry for a majorly delayed response. Looks like I have two rules for
this. They might be able to be optimized into one, but - I'm lazy too.

    
    
      com##IFRAME[src^="http://www.facebook.com/]
    
      ##IFRAME[src*="facebook.com"]
    
    

edit: Note - you need the 'Element Hiding Helper' that goes with Adblock Plus
to do this. Then you can just use that to select the iframe on a site and add
the rule through a nicer interface.

------
uptown
So potential solutions:

1\. Use NoScript

2\. Logout of social sites when you leave them

3\. Use separate browsers for social sites

None of those is a particularly convenient solution.

~~~
Zirro
If Firefox is your main browser, and you put NoScript in the "Allow Scripts
Globally"-mode, it's not much of a hassle.

------
encoderer
It sorta feels like we broke the web when it became the norm to stay logged-in
everywhere all the time.

Oops!

------
Johnyma22
Could be only me but twitter tries to redirect for me despite me being logged
in.

~~~
Johnyma22
oh I'm running disconnect.me -- might be relevant..

------
darkstalker
i see a small portion of the button not hidden by the div (firefox 12)

------
kposehn
Wow.

------
gcb
i can totally see one side of the button under the link on opera :D

