Re: [webappsec] straw man anti-clickjacking proposal

On 24/02/2012 00:56, David Lin-Shung Huang wrote:
> 
> 
> On Thu, Jan 5, 2012 at 2:56 PM, Michal Zalewski <lcamtuf@coredump.cx
> <mailto:lcamtuf@coredump.cx>> wrote:
> 
>     >> The content of IFRAMEs can be scaled down, rotated, etc, using CSS
>     >> transforms on the embedding page; what happens to the protected
>     markup
>     >> then?
>     >
>     > [Hill, Brad]  The protected markup would be rendered independent
>     of transforms on the embedding page.  The entire point is the
>     protected context gets render itself topmost and as-if-isolated
>     (cannot be moved, scrolled, scaled, etc. by outside influences), but
>     only while accepting input. (onmousedown / touch and hold)
> 
>     I wonder if this can be implemented cleanly if the protected markup
>     doesn't effectively occupy a separate and well-defined container. It
>     may be perhaps preferable to allow protected frames that are revealed
>     in their entirety, and are immune to CSS transforms?

IMO the protected markup should be rendered (albeit temporarily) in a
top-level "always on top" window, but clearly marked as a browser one
and with its origin well in sight, until the required additional
interaction is performed.

> For example, the attacker can use
> Flash Player's wmode or IE's createPopup() to obscure the victim element.
> 
> Here's a simple test page (not an attack demo):
> http://webperflab.com/david/test/obscure.html

David, I checked your page and:

1) I suppose you used opacity: 0.3 because that's the (arbitrary,
admittedly) threshold I set to bypass ClearClick checks and allow frames
to be translucent to some degree. Don't you think an UI is intellegible
enough at that level of transparency? If not, I could always change it.

2) I failed to understand how the Flash movie with wmode="direct" is
supposed to work against ClearClick. No matter where I clicked it, I
couldn't reach the button beneath. I even tried to add "pointer-events:
none" styling, but it didn't work either (kind of expected, since
wmode="direct" means more or less "go straight to screen and ignore
browser constraints as needed"). What am I missing here?

--
Giorgio