- From: Giorgio Maone <g.maone@informaction.com>
- Date: Tue, 07 Jun 2011 19:43:48 +0200
- To: David Lindsay <thornmaker@gmail.com>
- CC: Michal Zalewski <lcamtuf@coredump.cx>, sird@rckc.at, public-web-security@w3.org
David Lindsay wrote, On 07/06/2011 19.33:
> Also, there can be ui-redressing problems when everything on a page
> gets overlaid *except* the click-target element.
>
This can be handled by enforcing visibility of a reasonably sized area of the
owner document, centered on the click element (again, that's what ClearClick
does).
-- G
> 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:44:11 UTC