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

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

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

http://www.w3.org/TR/DOM-Level-3-Events/#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