Re: Remove paths from CSP?

On Thu, Feb 13, 2014 at 7:25 PM, Daniel Veditz <dveditz@mozilla.com> wrote:

> I think paths are valuable: many sites, not just major ones, have
>  sections where certain resources come from, and other areas that might
> contain user-supplied (user-influenced?) content.
>

Since I wrote the initial email, I've gotten feedback from several teams on
this thread and inside Google who have informed me that paths are, in fact,
quite important to them. I no longer believe that dropping paths is the
right way forward.

What other options do we have to keep some of the benefit of paths? We
> could support paths only up to a point, for example one or two segments
> in addition to the host name, perhaps requiring full segments (supply a
> terminal '/' if not specified in the policy) rather than allowing
> partial matches.
>

The concern with paths is that it gives a fairly granular mechanism of
brute-forcing the value of a redirect's location, both cross- and
intra-origin.

The nuclear option would be to simply allow redirects by checking only the
initial URL that's requested. That is, if
`https://example.com/script.js`redirects to `
http://evil.com/evil.js`, it would be allowed by `script-src
https://example.com`. That would avoid the problem of leakage entirely, but
weaken a policy's effectiveness.

Is this an option we'd like to pursue? Or are redirects too large a threat
to blindly allow?

For the record, Chrome is pretty good at catching redirects for most
resource types, but fails miserably at plugins: redirected Flash, Java,
etc. files currently exhibit the redirect-bypassing behavior described here.


> We could also reduce reporting. Is report-uri really a likely vector for
> this attack? I would think any effective attack would send boatloads of
> traffic to the attacker via report-uri, probably being detectable,
> definitely being slow, and maybe hard to correlate with an in-page
> attack on any given victim. Eliminating the in-page error event could
> help by forcing the attack to use report-uri exclusively.
>

I don't think reporting is really critical to the leakage. There is enough
data just from examining the page after the attempted load to determine
whether the load succeeded or failed. Egor's demo uses an <img> element's
`onload`/`onerror` events, but there are a number of other potential
vectors. Wost case, timing attacks would be effective, as you note at the
bottom of your email.


> We could and probably should reduce the amount of information sent in
> violation reports, especially when we've got information that the page
> itself doesn't know (that is, redirects). In particular, instead of the
> "stripped for reporting" of the blocked URL we could report the original
> URL that was found in the page. This would be more useful in the
> non-redirect case and doesn't leak information that the page could
> already know (e.g. via onerror/onload or by adding elements one at a
> time). In the redirect case doesn't leak information that an attacker
> couldn't otherwise know, such as user name if https://site.com/home
> redirects to https://<username>.site.com/ (stripping only protects
> against leaking information found in paths).
>

This is a good suggestion, regardless of whether we enforce against
redirects. I think it'll be a litttle bit complicated to implement in
Blink, as I think we've thrown away the initial request URL by the time we
get around to checking the redirect URL, but that's no reason not to make
the change to the spec:
https://github.com/w3c/webappsec/commit/59cf28abbc1c3f9db7bc26e03ba783322d28e74f

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