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

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

From: Robin Berjon <robin@robineko.com>
Date: Thu, 7 Oct 2010 16:18:36 +0200
Cc: ext Rich Tibbett <richt@opera.com>, "Oksanen Ilkka (Nokia-MS/Espoo)" <Ilkka.Oksanen@nokia.com>, "public-device-apis@w3.org WG" <public-device-apis@w3.org>, "Hirsch Frederick (Nokia-CIC/Boston)" <Frederick.Hirsch@nokia.com>
Message-Id: <8ABC81DA-0FDF-4A80-84F9-7FC858F16F3A@robineko.com>
To: Anssi Kostiainen <anssi.kostiainen@nokia.com>
On Oct 6, 2010, at 19:38 , Anssi Kostiainen wrote:
> 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.

Since infobars tend to push the viewport down and have their content in extremely predictable locations, their susceptible to a similar attack though (I forget the name): you create a game that requires that the user click a lot (e.g. kill the monkey), you move the target to where you want the user to click, and then you trigger the infobar. It does, however, have a small attack surface.

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

I agree that having a security review would be good, and I would suggest public-web-security as indeed a good source for such reviews. That being said, clickjacking is a larger issue that does indeed require its own solution. I think that the question for us is: can we go ahead with this in the expectation that clickjacking solutions will be there as well, or do we need to wait? I tend to suspect it's the former, but we should be sure.

Robin Berjon
  robineko  hired gun, higher standards
Received on Thursday, 7 October 2010 14:19:06 UTC

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