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 11:42:42 -0500
Message-ID: <BANLkTikBRRNU8WhoAX1pakXRCkBxnSaNug@mail.gmail.com>
To: Michal Zalewski <lcamtuf@coredump.cx>
Cc: public-web-security@w3.org
@Michal

> 1) What do you do when you have two overlapping "always on top"
> elements? You can only render one.
Yes, that's why I added the bit of "only works when hovered over". You
can only hover one pixel at a time, so I hope you can only hover over
one element at a time.

> 2) What if the button is visible (and therefore interactive), but only
> for a very short period of time before a premeditated click (not
> enough to give the user a chance to respond)?
This is something the host page could detect right? How long the mouse
is hovered over.

> In general, I had the impression that vendors were very unhappy about
> implementing any solutions to clickjacking that would involve
> determining the actual on-screen visibility of a rendered element,
> because that can be complicated in some settings

Well, we can kinda do this now a days, on IE with createPopup, and on
other browsers with Flash with wmode (of course, both can be obscured
by the very same mechanisms, that's why I added the "one element at a
time" restriction), so doing this shouldn't be very hard (of course,
I'm not sure, but it sounds like it might not be so hard).

Do you have a pointer to that last proposal? I missed that conversation.

Greetings!!

-- Eduardo




On Tue, Jun 7, 2011 at 11:36 AM, Michal Zalewski <lcamtuf@coredump.cx> wrote:
>> <style>
>> #buyButton:hover{
>>    visibility: forced;/* or something else, I don't know.. */
>> }
>> </style>
>> <button id="buyButton">Click here to purchase server for $500.00.</button>
>
> I see two potential problems here:
>
> 1) What do you do when you have two overlapping "always on top"
> elements? You can only render one.
>
> 2) What if the button is visible (and therefore interactive), but only
> for a very short period of time before a premeditated click (not
> enough to give the user a chance to respond)?
>
> In general, I had the impression that vendors were very unhappy about
> implementing any solutions to clickjacking that would involve
> determining the actual on-screen visibility of a rendered element,
> because that can be complicated in some settings (my proposal in 2008
> was shot down on these grounds).
>
> /mz
>
Received on Tuesday, 7 June 2011 16:43:29 UTC

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