RE: New clickjacking research published

From: Fred Andrews [mailto:fredandw@live.com]
Sent: Tuesday, September 11, 2012 6:42 AM
To: Hill, Brad
Cc: public-webappsec@w3.org
Subject: RE: New clickjacking research published

<snip>
In contrast the Incontext design compares the OS-level view "what the user sees" and this could
include even extension chrome which would make it problematic to work with extensions - or even
with standard browser chrome such as pull down menus or developer tools.

[Hill, Brad] The spec recommends that it should not interfere with extensions - but how this can be accomplished is going to be highly specific to the user agent, the capabilities it offers to extensions and how they are implemented.  As with the trickier edge cases on most specifications, we will need to document best practices as they emerge, but they are unlikely to emerge absent actual implementation experience.

ClearClick will prompt the user in case of a detected issue.  Your proposal does flag a UIEvent
but there appears to be no mention of how a web browser default handlers would respond to
such events.  Perhaps a suggestion to have browsers inform users could be added to the document
if appropriate.

[Hill, Brad] We deliberately recommend *against* informing the user. 99.9999% of users are unprepared to understand and respond appropriately to this kind of warning and, as such, there is zero interest among browser vendors in adding yet another useless security pop-up warning.  Resource owners can use the 'unsafe' flag to add their own warning, or, as we recommend, allow the click and use 'unsafe' or the reporting feature to apply anti-fraud controls on the back-end without impacting the user experience.

Would you happen to know if CSS alone can be used for timing attacks?  Perhaps using transitions.
If so then perhaps transitions would need to be checked or restricted if ever adding CSS checks.
[Hill, Brad] A screenshot based approach should be agnostic to whatever techniques are used - it's just pixels.  That's one of the primary advantages of the technique.
<snip>

Thank you for the perspective.  Are standard buttons and forms 'widely loathed' by content authors or by users (or both)?

It would seem that a good deal of customization could be permitted without UI redress concerns.

A suggestion to add standard social networking and payment widgets may not be well received then.

[Hill, Brad] While it wouldn't take a moment to find an exception I'm sure, I actually don't recall seeing recently any 'standard' (native OS or browser styled) buttons on any of the web properties I regularly visit. To my recollection "buttons" these days are pretty much all heavily CSS styled, images, or non-form interactive content elements hooked up to JS eventing.
We really want to address a general-case issue here with a solution that doesn't impair the creativity of designers, not build components that are specific to use-cases like "social" or "payment".
I made a straw-man proposal last year somewhat along the lines of what you are suggesting, and it indeed did not generate much interest:
http://www.w3.org/Security/wiki/Anti-Clickjacking_Protected_Interactive_Elements
-Brad