W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2012

Re: [webappsec] straw man anti-clickjacking proposal

From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Thu, 5 Jan 2012 14:56:14 -0800
Message-ID: <CALx_OUBMs5Z8eCXV-Y=rsz9kv764-xP3xhRnVE7gM3H8evgo6Q@mail.gmail.com>
To: "Hill, Brad" <bhill@paypal-inc.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
>> 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?

> [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
Received on Thursday, 5 January 2012 22:57:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 5 January 2012 22:57:04 GMT