- From: <sird@rckc.at>
- Date: Tue, 7 Jun 2011 12:43:03 -0500
- To: David Lindsay <thornmaker@gmail.com>
- Cc: Michal Zalewski <lcamtuf@coredump.cx>, public-web-security@w3.org
Yup David, that's why the provider of the widget should choose wisely
what he wants to protect (eg. protecting the "Continue" button isn't
that useful).
In NoScript, clearclick forces the whole form to be visible, so if you
want to protect a form, you might want to do that.. But ideally you
only want to protect a very specific part of the document eg. an ad, a
like/+1 button, etc..
-- Eduardo
On Tue, Jun 7, 2011 at 12:33 PM, David Lindsay <thornmaker@gmail.com> wrote:
> Also, there can be ui-redressing problems when everything on a page
> gets overlaid *except* the click-target element.
>
> On Tue, Jun 7, 2011 at 12:36, 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 17:43:50 UTC