W3C home > Mailing lists > Public > public-web-security@w3.org > June 2011

Re: Req for feedback? Add attribute to elements to defeat clickjacking

From: <sird@rckc.at>
Date: Tue, 7 Jun 2011 22:35:20 -0500
Message-ID: <BANLkTinpVDSxhaxy7C961B1JOXf1JrxKUg@mail.gmail.com>
To: Michal Zalewski <lcamtuf@coredump.cx>
Cc: public-web-security@w3.org
Hi!

Made a simple PoC (it's IE only! won't work on any other browser):
http://commondatastorage.googleapis.com/sirdarckcat/work/etc/clickjacking-attack.html

As Michal mentioned it's still vulnerable to timing attacks, when the
attacker can predict when the user will click faster than he can
regret clicking.. I didn't implemented anything related to that, but
could be done by monitoring mouse events.

I am using createPopup to do the trick. The target for an attacker
would be to make the "this click was not clickjacked" dialog appear
with clickjacking.

Greetings!!

-- Eduardo




On Tue, Jun 7, 2011 at 3:47 PM, Michal Zalewski <lcamtuf@coredump.cx> wrote:
>> Yes, so making this configurable from within the feature
>> (force-visibility: none | Ns) would make this better?
>
> Possibly. This is a bit more tricky, because you also need to handle
> moving frames / windows, etc, but in general, yup.
>
>> Also, I read the previous conversation in WHATWG, but couldn't find
>> anything regarding this, you mean the solution (2)? or (3)?
>
> I haven't proposed on-top attribute, but proposal (3) had similar
> considerations in terms of ensuring that the element is not obstructed
> (instead of force-on-top, it had something like only-work-if-on-top),
> and in terms of the need to ensure some amount of uninterrupted screen
> time, sufficient dimensions, etc. I suspect that these aspects were
> one of the reasons why people hated it back then.
>
> Now, arguably, neither of the proposals is strictly hard: IIRC, Flash
> is already doing "am I visible" checks by scraping the screen (or so I
> was told, haven't looked at their implementation).
>
> PS. I wouldn't dismiss keyboard input too quickly. Some webpages
> auto-focus certain buttons or form fields, and you can focus() on the
> container frame itself first. In such a situation, a single <space> or
> <return> keypress may have some unintended consequences. Perhaps not
> for existing "like" buttons, though.
>
> /mz
>
Received on Wednesday, 8 June 2011 03:36:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:19 UTC