Re: [webappsec] straw man anti-clickjacking proposal

On Thu, Jan 5, 2012 at 2:56 PM, Michal Zalewski <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?
>

Implementations would also need to consider there are existing non-CSS
methods that can obscure elements. 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


> > [Hill, Brad]
> > Again, since the requirement would only apply when the control is
> receiving focus.  I don't know of any window managers that allow changing
> or obscuring of a window when it is currently accepting input.
>
> The comments I received back then is that it's difficult to determine
> if a control receiving focus is indeed visible fully on the screen to
> begin with, especially when also dealing with, for example,
> hardware-accelerated video playback. But as noted, I doubt it's an
> impossible obstacle.
>
> > [Hill, Brad] Again, the implementation would have to prevent this, but
> only while the control had onmousedown, which I expect is simpler than
> trying to do so (or monitoring for such hijinks) continuously.
>
> I think it would be useful to hash it out in the proposal; there is a
> prohibition on "moving", but the naive interpretation is that it
> applies to scrolling the document, and not necessarily moving around
> the window, or opening new ones. Unless the action also stops
> JavaScript execution and all pending requests, there is also a
> potential that after the action is initiated, critical information is
> obscured with alert('...'), a HTTP 401 password prompt, or other modal
> dialogs.
>
> Other changes that aren't strictly "motion" but may reposition or
> obscure elements are things such as going into or exiting the
> full-screen mode (via Flash or HTML5).


> Cheers,
> /mz
>
>