Re: Remove paths from CSP?

On 2/12/2014 12:28 AM, Mike West wrote:
> Exposing path information makes it fairly easy to leak data
> cross-origin.  I noted this in May last year[1], but [2] and [3] shows
> that it's far more practical than I thought at the time.
> 
> Are paths valuable enough to live with this leakage vector? I don't
> think they are.

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.

> I'd suggest dropping paths from 1.1 now, before LC, and removing them
> from both Chrome and Firefox's implementation. We might be able to keep
> paths for some directives ('form-action' for instance, which might
> mitigate some of the concerns in Michal's Postcards), but I'm not sure
> that complexity is worthwhile.

We should not support paths in some directives and not others. That kind
of complexity and inconsistency will confuse people into using paths
where they aren't supported and thinking their policy gives them more
protection than it does.

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.

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.

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

I'm not too concerned about CSP being used to determine if someone is
logged in to a particular site or not, because timing attacks are good
enough to figure that out for most sites already. We shouldn't let
people use CSP to figure out user names or tokens or similar path segments.

-Dan Veditz

Received on Thursday, 13 February 2014 18:25:55 UTC