RE: New clickjacking research published

<hat=editor>

Thank you for your comments, Fred.  I've updated the Implementation Considerations section of our editors' draft spec to reflect some of your concerns, and I'd encourage you to review what we're considering specifying, as it is informed by, but certainly not identical to, David's work.

http://dvcs.w3.org/hg/user-interface-safety/raw-file/tip/user-interface-safety.html

I have some concerns with your proposed alternative approach:

"UI widgets would be limited to a standard set with well known and
 expected behavior - standard buttons and forms etc. ... This may
limit the scope of customization that a web application can achieve in
such contexts but this seems like a small price to pay.  This approach
is also consistent with the roots and success of the web.  It builds on
user experience and expectations for the operation of a standard set
of widgets."

I think our experience with the web is actually the opposite - that standard buttons and forms with limited customization are widely loathed and rarely used, even when the cost in security is quite high.  Perhaps the biggest reason that we are still stuck using insecure, plaintext password, forms-based auth instead of more secure and phishing-resistant methods is that application owners value the ability to have full control, customization and branding of their login experience above almost all else.  They absolutely hate the current experience of HTTP based auth, and user agents have not been able to arrive at any agreement on how to present it in a standardized manner that is any more palatable to application authors.

We also would greatly prefer to arrive at a solution that can be applied to existing applications few or no changes.  The most used and most attacked scenarios today, buttons like "like", "+1", "Pay", etc. are all small and highly customized, with high information density and quick visual differentiation being perhaps the top design considerations.  A standard widget set can't meet those requirements.

Brad Hill

From: Fred Andrews [mailto:fredandw@live.com] 
Sent: Monday, September 10, 2012 6:36 PM
To: Hill, Brad
Cc: public-webappsec@w3.org
Subject: Re: New clickjacking research published

> Our UI Safety co-editor, David Lin-Shung Huang, has been doing some stellar anti-clickjacking research in the last year and a half.  We've been discussing ideas and implications from his research for the full lifetime of the WG, and I'm happy to announce that the final paper is now available to read after he presented it at USENIX Security last week:

> http://websec.sv.cmu.edu/clickjacking/clickjacking.pdf

> Congratulations to David, and highly recommended reading for anyone interested in the new spec.

Thank you for posting the link.  This is an interesting paper.

"5.1.1 Guaranteeing target display integrity.
...
Since only application know which UI elements require protection, ..."

This may not be a good assumption.  The user may well want all their
UI elements to be consistent with their expectations.  The UI elements
that are a concern to the user may also be a private matter.  A
solution would ideally take these user driven concerns into account.

"Strawman 1: CSS checking."

This solution does not seem practical for web browsers because the CSS can be
customized by the client.

"Strawman 2: Static reference bitmap."

This solution does not seem practical for web browsers because the rendering
is entirely a matter for the client.  The client may well overlay
info boxes or warnings etc and this is a private matter for the client.

"Our design. InContext enforces target display integrity by comparing
the OS-level screenshot of the area ..."

This solution does not seem practical for web browsers because the
client may have good reason in normal operation for the OS-level
screenshot of the area to not be consistent with the same screenshot
of the area with the 'sensitive' element alone.  Given client
extensions, it may not be possible to obtain a screenshot of the area
with the sensitive element alone.  Further, as noted above the
'sensitive' elements should also be definable by the client.  If
the client decides that the entire document is sensitive then this solution
would make the entire document unusable if the client is using
extensions etc and if comparing OS-level bitmaps then even browser
chrome could inhibit operation.

Ideally any solution would take into account privileged client
extensions that may well customize the visual content.  Such
extensions may well be an important part of the users security.

An alternative approach may be to add a restricted mode of operation
that could be flagged for parts of the DOM in which CSS is constrained
and outside influences restricted.  This could use a sticky flag to
prevent it being reset by malicious code or might not be accessible to
JS.  Within this context, UI widgets would be limited to a standard set
with well known and expected behavior - standard buttons and forms
etc.  This approach would still allow the client to implement extra
information cues, checks, and prompts within this context at the
discretion of the user.  For example some users may prefer to vet all
outgoing forms in some contexts, such as when banking.  This may
limit the scope of customization that a web application can achieve in
such contexts but this seems like a small price to pay.  This approach
is also consistent with the roots and success of the web.  It builds on
user experience and expectations for the operation of a standard set
of widgets.

cheers
Fred

Received on Tuesday, 11 September 2012 02:20:39 UTC