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

Timing-related clickjacking might also be worth considering, for
example, putting a fully-visible FB like button on the page, and moving
it under the mouse cursor right before the user clicks on the page.
We've seen interesting solutions in this area: Flash Player's camera access
button forces a timeout before allowing user click whenever changing focus
or repositioning the element. The idea is close to Michal's original
proposal.

David Huang

On Tue, Jun 7, 2011 at 10:43 AM, Giorgio Maone <g.maone@informaction.com>wrote:

> 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
> >>
> >>
> >
>
>
>