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

Re: UI Safety - input protection obstruction check challenges

From: Giorgio Maone <g.maone@informaction.com>
Date: Wed, 12 Sep 2012 15:16:13 +0200
Message-ID: <50508B1D.5060603@informaction.com>
To: Fred Andrews <fredandw@live.com>
CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
Hi Fred,

thank you very much for sharing your considerations.

On 12/09/2012 14:40, Fred Andrews wrote:
> Some more challenges for the UI Safety obstruction check.
> 
> * Widgets implemented by multiple embedded frames that work together and
> can overlap under normal operation.
> 
> For example, the website http://googlewebmastercentral.blogspot.com/
> embeds google+1 buttons but these are not embedded in the manner
> anticipated by the UI Safety proposal and can trip ClearClick

I'm afraid I couldn't reproduce the issue, and I'd like to. I'm not
triggering ClearClick neither by using the widget on the top left,
neither (quite obviously) by clicking on the bare image button on the
right column.

If you're, could you please use the "Report" button on the ClearClick
dialog and send me the report ID for analysis? Thank you.

> It's is not clear that there is a solution to this issue, apart from
> restricting the input protection to apply to lone widgets.

Actually I believe that if and when the protection is standardized, web
authors are gonna discover problematic embedding patterns (which seem to
be edge cases anyway) and learn how to work around them.

After all, the current "solution" which mandates an extra
"X-Frame-Options: Deny" confirmation page is incomparably more
cumbersome than any restriction on how the embedding must be positioned
and presented "in the clear" for it to be responsive.

> Note that this same website implements the Twitter and Facebook buttons
> as plane navigation buttons, not as functional widgets! 

That's because they delegate the authenticated transaction to the
aforementioned intermediate page.

> *  CSS transforms may frustrate the Obstruction check.

And they can also be used to actually mount an effective Clickjacking
attack, hence the test failing and the protection being triggered is a
feature, rather than a bug, IMHO.

> Perhaps the algorithm could be adapted, applying the widget frames
> current transform matrix to the widget document and also to the bounding
> box used for comparison, but this does seem like a research project.

If the obstruction check accommodated for CSS transforms, I'd consider
it an exploitable weakness for the reason above. I believe "don't use
CSS transforms to alter the widget appearance" is one of those
restrictions which web authors should learn to live with.

-- G
Received on Wednesday, 12 September 2012 13:16:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 12 September 2012 13:16:34 GMT