- From: Giorgio Maone <g.maone@informaction.com>
- Date: Wed, 12 Sep 2012 15:16:13 +0200
- 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 UTC