Re: Remove paths from CSP?

The browser could complete the network request, even if it is blocked by 
CSP, then check it against the Same Origin Policy. It should then only 
report a CSP violation if the sub-resource was allowed by the Same 
Origin Policy but blocked by CSP.

If the Same Origin Policy blocked the inclusion of the sub-resource, CSP 
would not leak any information. You would then not get a CSP report, but 
since nothing would have happened, even without CSP, that might be OK.

If the Same Origin Policy allowed the inclusion of the sub-resource, 
that would already leak information about the resource, even without 
CSP. CSP might increase the amount of information leaked, but that is 
not nearly as serious as leaking information where none were leaked 
before. By reporting the original requested URL instead of the final 
redirected one, as others suggested, we might even be able to eliminate 
the expansion of the leak.

By the way, isn't this entire discussion an additional point for why we 
need something that does what the From-Origin header tried to do?

-
Jesper Kristensen

Den 12-02-2014 09:28Mike West skrev:
> CSP 1.1 allows authors to add path information to source expressions.
> It's implemented in both Firefox and Chrome. Generally, it seems like a
> reasonable thing to want to limit script to 'mycdn.com/js
> <http://mycdn.com/js>', as it limits exposure. I argued for this feature
> back in 2012, and implemented it in Chrome. I think I was wrong to do so.
>
> 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'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.
>
> CCing some folks from previous discussions. WDYT?
>
> [1]: http://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html
> [2]: https://code.google.com/p/chromium/issues/detail?id=313737
> [3]:
> http://homakov.blogspot.de/2014/01/using-content-security-policy-for-evil.html
>
> --
> Mike West <mkwst@google.com <mailto: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.)

Received on Monday, 17 February 2014 09:30:16 UTC