W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2010

Re: Clickjacking (was: window.open() and popup blockers)

From: Rich Tibbett <rich.tibbett@gmail.com>
Date: Wed, 6 Oct 2010 20:32:56 +0200
Message-ID: <AANLkTinvsgOhSp4T5RDmaXKO97ky5gFo1F_7XkjS=xQX@mail.gmail.com>
To: "public-device-apis@w3.org WG" <public-device-apis@w3.org>, Anssi Kostiainen <anssi.kostiainen@nokia.com>
Cc: Rich Tibbett <richt@opera.com>, "Oksanen Ilkka (Nokia-MS/Espoo)" <Ilkka.Oksanen@nokia.com>, "Hirsch Frederick (Nokia-CIC/Boston)" <Frederick.Hirsch@nokia.com>
On Wed, Oct 6, 2010 at 7:38 PM, Anssi Kostiainen <anssi.kostiainen@nokia.com
> wrote:

> Hi,
> On 4.10.2010, at 13.57, ext Rich Tibbett wrote:
> > I have added a section to the Contacts API spec entitled 'API Invocation
> > via DOM Events' + an example of its usage. It is included informatively
> > and might be worth a read:
> >
> >
> http://dev.w3.org/2009/dap/contacts/Overview.html#api-invocation-via-dom-events
> Thanks. A concrete proposal is a good way to start mulling this one. Before
> going full steam ahead with the approach I'd like to make sure we won't
> increase the attack surface too much.
> Some of us surely remember e.g. the Flash webcam clickjacking exploit [3].
> I'd guess a similarly constructed attack could be used to trick the user in
> displaying a contact picker, from where the confused user could proceed to
> share his/her contact information with a malicious party. In Capture
> constructing a similar attack would be even easier due to simpler file
> picker interaction. AFAIK this type of an attack does not work with an
> asynchronous infobar which is outside of the viewport and not within the
> top-level browsing context, and thus is not accessible by script.
> Below are couple of good references on clickjacking I found:
> - Clickjacking article by the Open Web Application Security Project, OWASP
> [1]
> - Busting Frame Busting: a Study of Clickjacking Vulnerabilities on Popular
> Sites by the Stanford Web Security group [2] (cited by the OWASP article)
> - Clickjacking exploit explained by Jeremiah Grossman and Robert Hansen,
> who coined the term clickjacking (describes the original Flash webcam
> exploit) [3]
> I looked into public-web-security ML but found very little discussion on
> clickjacking. Basically there was a one thread regarding HTML5 iframe
> sandboxing concluding X-Frame-Options HTTP header would be the solution [4].
> The Stanford paper [2] seem to also conclude X-Frame-Options is the
> long-term solution. This Week in HTML5 also discusses potential workarounds
> [5].
> I guess we could benefit from a review by web security experts at this
> early stage of the design. What would be the best venue to conduct that?
> -Anssi
> [1] http://www.owasp.org/index.php/Clickjacking
> [2] http://w2spconf.com/2010/papers/p27.pdf
> [3] http://www.sectheory.com/clickjacking.htm
> [4]
> http://lists.w3.org/Archives/Public/public-web-security/2009Dec/0132.html
> [5] http://blog.whatwg.org/this-week-in-html-5-episode-7

Rather than taking clickjacking as the jumping off point perhaps focusing on
preventing/managing 'synthesized click events' is the way to go here.

I'd like to solve the more general problem of clickjacking but short of
rewiring the whole web platform I worry it's not going to lead to any
actionable outcomes for the DAP WG. It's a serious issue but probably not
one suited for tackling in this group. I may, of course, stand corrected on

Instead, I believe the answer lies in enforcing the DOM Level 3 Events
specification behaviour around "user-initiated activation triggers" and
"trusted" events:


I certainly see a few areas on these topics that we could address in our own
spec...but more on that later when I have a proposal.

- Rich
Received on Wednesday, 6 October 2010 19:02:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:23 UTC