Re: New clickjacking research published

Thanks for reading our paper.

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 <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 go through?

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

Cheers,
David

>
> cheers
> Fred
>
>