Re: Remove paths from CSP?

On 2/14/2014 12:33 AM, Mike West wrote:
> The nuclear option would be to simply allow redirects by checking
> only the initial URL that's requested. [...] That would avoid the
> problem of leakage entirely, but weaken a policy's effectiveness.
> 
> Is this an option we'd like to pursue?

No! That would mean a policy was effectively useless if any whitelisted
domain had a redirector--and in the case of 3rd party sites the author
might not know if they did and certainly has no control over it. It's
worse than "weaken".

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

Plugins are definitely hard since they don't know anything about CSP and
do some of their own network requests. I don't think we should limit the
specification to what we can technically achieve on legacy desktop
browsers. As HTML gets more powerful more plugin content drops away, and
mobile browsers are largely free of plugins.

Possibly worth a note in the spec that redirects are not always caught
in the plugin case and that "object-src 'none';" is the safest policy.
The object-src directive was included to accommodate legacy content much
like 'unsafe-inline'.

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

That's the hard part. If it were just reporting we could solve that
easily (make reporting off by default, or only in beta versions). It
would be sad to lose reporting but woudn't be the death of CSP. But it
goes deeper -- CSP is designed to prevent things from loading, and it
may be impossible to hide the fact that something loaded or didn't.

> 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

Thanks. redirects definitely complicate things. So even if we're
reporting on the resource in the page you think we still have to do the
"stripped for reporting" step?

-Dan Veditz

Received on Saturday, 15 February 2014 00:38:09 UTC