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: Tue, 28 Feb 2012 02:30:25 -0800
Message-ID: <CAGiwpwg2+kdujgicFZGT-PFqUQaPbNomehHBzca8D=4Ym=fR9g@mail.gmail.com>
To: Giorgio Maone <g.maone@informaction.com>
Cc: Michal Zalewski <lcamtuf@coredump.cx>, "Hill, Brad" <bhill@paypal-inc.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Tue, Feb 28, 2012 at 12:48 AM, Giorgio Maone <g.maone@informaction.com>wrote:

> 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.

No problems with that. That specific example wasn't meant to be a
ClearClick bypass.

> 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?

My main point was to demonstrate that Flash Player can currently draw on
top of any element rendered by the browser. With that, an attacker could
use Flash movies to obscure parts of a protected element, and trick users
to click on the unobstructed areas of the protected element (perhaps a
1-click buy button within a masqueraded checkout dialog).

I assumed that ClearClick intends to detect any visible obstruction on the
clicked frame (a Twitter button in the test page), but saw that it didn't
detect the Flash movie on Windows.

That said, it should be possible to detect or avoid this from the browser
(e.g. taking OS screenshots for comparison).


> --
> Giorgio
Received on Tuesday, 28 February 2012 10:30:58 UTC

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