RE: New clickjacking research published

Date: Mon, 10 Sep 2012 19:22:19 -0700
From: linshung.huang@sv.cmu.edu


On Mon, Sep 10, 2012 at 6:36 PM, Fred Andrews <fredandw@live.com> wrote:




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

> I'm not sure if I understand your point. Are you proposing that if an extension changes the
> appearance of a sensitive element, such as changing styles or removing banners on a checkout
> dialog, the site (e.g. PayPal) should not notice, and should always allow the payment clicks to gothrough?

It's not a technical matter, but my view is that private customization by the user should remain private.

For example, parents should be able to install extensions to prevent their children submitting PayPal
orders without the matter being reported back to PayPal.  PayPal's website and checkout process appears
to work without JS even enabled, so I don't see the big issue here?

This is a difficult issue to untangle.  I appreciate that PayPal may see this differently.


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.
> If UI widgets are limited to standard buttons, you have excluded Facebook's like button,
> Twitter's follow button, PayPal's checkout frame, and pretty much every modern web site
> from adopting the defense.

It's not that bad.  Try browsing with JS disabled.  There are lots of twitter buttons that still
navigate to twitter etc, e.g. http://slashdot.org/   Lots of PayPal checkout buttons on shopping
carts that still work.  Google, Amazom, eBay, Bing, still work.    A good user experience is still
possible (some might even find it quite refreshing) and if it avoids complex safety issues
then this would suit many users.   We don't even need to disable JS to address the issue
at hand, just restrict it in some contexts, so there would be lots of scope.  Buttons and forms
could still be heavily customized, just limited to address the issues at hard, and this need only
be done in some contexts.

Creative control over UI widgets conflicts with consistency of user experience.  UI redress is by
definition an unexpected UI, so creative control over the UI conflicts with limiting UI redress.

Locking down the user client and implementing reporting just seems like too high a costs for
the limited gain of improved safety for some unnecessary embedded widgets.  There is some
similarity to DRM.  If users don't like it they will just disable it anyway, and nothing is gain,
just a lot of unnecessary complexity.

We can also look at adding new UI widgets to HTML to meet common patterns such as social
networking and there are other approaches to address these issues.  For example, I understand
that Firefox is working on better integration of social networking within the browser to help
move away from these widgets appearing everywhere.
https://wiki.mozilla.org/Firefox_Social_Integration

cheers
Fred