W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2011

[whatwg] Allowing Clickjacking Prevention using a Minimal Javascript API

From: Rob Ennals <rje@google.com>
Date: Wed, 17 Aug 2011 15:51:39 -0700
Message-ID: <CAJsGU-oFi2jqhs4fNYq94S7H+eQrCfr9E5aqpDjpU9LztzN3Eg@mail.gmail.com>
Hi Guys,

I'd like to present a proposal for a minimal API that would allow
clickjacking prevention, while still allowing useful cross-domain
iframing such as share buttons etc.

(for context: http://en.wikipedia.org/wiki/Clickjacking)

To allow an iframe to detect clickjacking, the browser would provide
API functions to determine the following:
* The origins of all enclosing documents
* The size of the iframe viewport
* Whether any of the iframe content might be covered by something else
    - scrolled into view, and no overlapping rectangles with higher z-order
* It's absolute position in the window
* The complete computed style applied to the iframe (e.g. is it zoomed
or transparent)
* Receive an event whenever any of these change
* Any other information I've forgotten that might indicate clickjacking


The intention is that the browser would expose sufficient information
to allow the iframe to detect clickjacking if it happens.
Responsibility for detecting clickjacking is passed over to the iframe
javascript. The browser just gives the iframe the tools it needs to do
it's job.

A developer would not be expected to implement clickjacking detection
themselves. Instead they would import a standard library that does it.
Such a library could be included as a default part of libraries like
Closure and jQuery.


Several proposals for preventing clickjacking have been proposed
before, but, as yet, browsers do little to prevent clickjacking, other
than X-Frame-Options, which disallows cross-domain iframing
completely.

Michal Zelewski sent out an interesting proposal back a while back,
but that seems to have been rejected on the grounds that it was
complex to implement, and it wasn't clear that the proposed solution
would be the correct one in all use cases.
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-September/016284.html

NoScript's ClearClick also does similar client-side checking.


The motivation behind the proposal above is:
* Make it be something that is minimal enough that browser vendors can
implement it relatively easy.
* Don't make any claims about it being complete. Instead allow library
vendors to explore the appropriate rules to use to disallow
clickjacking.


Thoughts?


Thanks

-Rob
Received on Wednesday, 17 August 2011 15:51:39 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:35 UTC