W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2014

Re: CSP: 'no-external-navigation'?

From: pamela fox <pamela.fox@gmail.com>
Date: Mon, 30 Jun 2014 15:51:19 -0700
Message-ID: <CAEVChv1aH+wh1gGhf_VQysc7VBEku2kLFuzdoRGtQ1Cj8wDQPQ@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Michal Zalewski <lcamtuf@coredump.cx>, "public-webappsec@w3.org" <public-webappsec@w3.org>
To clarify our situation again, since it's not showing me the full thread:

We have a live coding environment at http://khanacademy.org/cs/new where we
run the code created by the user, in the iframe on the right (which is
hosted at kasandbox.org)

Thanks to content-security-policy, we will be able to prevent the user from
doing a host of undesirable things with their code - making XHRS and JSONP
calls, loading external multimedia.

However, we're currently unable to block them from changing
window.location, so they can navigate that iframe
away. To see that, move your mouse over the right hand side here:

The concerning aspect of this is that it can be used for something like
phishing attacks, to solicit and store user info.

I tried various hacks to disable that, like via beforeonunload, but none
were successful. Details here:

It seems like a CSP directive could be just what we need -- a header we can
set on that iframe to block attempts to navigate away by changing

It is entirely possible we are an edge case. There is an increasing number
of live coding environments, however.

On Mon, Jun 30, 2014 at 1:26 PM, Mike West <mkwst@google.com> wrote:

> +Pamela
> --
> Mike West <mkwst@google.com>
> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
> Geschäftsführer: Graham Law, Christine Elizabeth Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
> On Mon, Jun 30, 2014 at 8:45 PM, Michal Zalewski <lcamtuf@coredump.cx>
> wrote:
>> > We've talked briefly about similar concepts in the past in the context
>> of
>> > the next iteration of CSP; at first glance it seems like something that
>> > might be useful in narrow use-cases, but that I'm worried will be
>> abused to
>> > keep folks on pages they don't particularly want to be on (see  what
>> > happened with `window.onbeforeunload` modals).
>> If I read this correctly, the request is to prevent programmatic
>> navigation within the CSP-sandboxed frame, not prevent the user from
>> relying on bookmarks, manually entered URLs, etc.
>> That said, I'm not sure this is a very meaningful goal if you're
>> otherwise permitting largely unconstrained JS to run on the page (and
>> you're using CSP to "sandbox" it) - what would be the goal? Can't the
>> JS achieve roughly the same without navigating its own frame away?
>> /mz
Received on Tuesday, 1 July 2014 08:03:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:39 UTC