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

@Giorgio

That's a good point, I think that for touch-screen devices the
implementor could prompt the user for confirmation, or something
similar.

Another thing we could do is that if the user put's his finger over
one of this elements, the element is made visible until the user
releases it.. However given that phones are so small compared to our
hands/fingers, it might not be that useful, but might be good enough for
tablets and so?

Greetings
-- Eduardo




On Tue, Jun 7, 2011 at 11:31 AM, Giorgio Maone <g.maone@informaction.com> wrote:
>> Let's say we add an attribute (or CSS property) that will instruct the
>> browser that when hovered, they should appear over everything that
>> might be over them, and make it's opacity opaque.
>
> What about smart phones and tablets ("tap" devices) where hovering never
> happens? Not exactly a rare use case these days...
>
> -- G
>
> Eduardo Vela wrote, On 07/06/2011 18.20:
>> Hi!
>>
>> One of the most complicated problems we have now a days is that there
>> are some widgets which are specifically designed to be iframed (ads,
>> games, like buttons, etc..) are difficult to protect against
>> clickjacking.
>>
>> So, there's this idea that might solve some of those problems.
>>
>> Let's say we add an attribute (or CSS property) that will instruct the
>> browser that when hovered, they should appear over everything that
>> might be over them, and make it's opacity opaque.
>>
>> So something like:
>>
>> <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>
>>
>>
>> Will make the buy button visible no matter if there are things over it
>> (in other windows).
>>
>> There are some restrictions that should be made for this to be effective:
>> 1. This property should only work on hover, or active elements (eg.
>> with the mouse over, or selected by <tab>).
>> 2. If this is inside an iframe, then it shouldn't obscure anything
>> outside of the frame window (so, if there's a 1x1 frame, the button
>> will still be invisible).
>> 3. If part of the element is outside of the window (eg.
>> top:-200;left:-200), it shouldn't obscure chrome UI (like the
>> addressbar or so).
>>
>> To mitigate against attacks abusing (2) or (3) if the "forced
>> visibility" fails, then mouse click events to that object could be
>> disabled, but even if nothing is done it would be ok, since the frame
>> can detect it's size and position (so it would know that the click
>> might be invalid).
>>
>> I was wondering if you can find any other (abuse) cases for this
>> feature, or if you have any thoughts. Or if there might be other
>> (better) solutions for this problem.
>>
>> Greetings!!
>>
>> -- Eduardo
>>
>
>

Received on Tuesday, 7 June 2011 16:38:21 UTC