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

Re: [webappsec] straw man anti-clickjacking proposal

From: David Lin-Shung Huang <linshung.huang@sv.cmu.edu>
Date: Thu, 23 Feb 2012 15:56:09 -0800
Message-ID: <CAGiwpwjv+=2QwrSwjC+Su63RHfguB3EACBVZJwv42OJWaZGaaw@mail.gmail.com>
To: Michal Zalewski <lcamtuf@coredump.cx>
Cc: "Hill, Brad" <bhill@paypal-inc.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
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):


> > [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, 23 February 2012 23:56:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:26 UTC