Re: Paths and Redirects

thanks a lot Mike.

appreciated that…

so the proposal addresses only the brute force case..

regards

antonio

On Aug 18, 2014, at 9:28 AM, Mike West <mkwst@google.com<mailto:mkwst@google.com>> wrote:

Hi Antonio!

On Fri, Aug 15, 2014 at 4:37 PM, Antonio Sanso <asanso@adobe.com<mailto:asanso@adobe.com>> wrote:
hi *,

in [0] I see a section that has been written in order to address the issue spotted by Egor Homakov in [1].
Now I might have well misunderstood the all story but IMHO this doesn’t seem to solve the original issue.
E.g. if we have

img-src<http://www.w3.org/TR/CSP11/#img-src> example.com<http://example.com/>

rahter than

img-src<http://www.w3.org/TR/CSP11/#img-src> example.com<http://example.com/> not-example.com/path<http://not-example.com/path>

what is going to happen?
AFAIU the redirect to not-example.com<http://not-example.com/> will still happens hence the leaking.

I'm not sure I understand the question, but let me try to explain what the spec intends:

1. We don't have a good solution for preventing detection of a redirect from `example.com<http://example.com/>` to `not-example.com<http://not-example.com/>`. The WG weighed the risk of cross-origin leakage against the value of the reporting feature in general, and decided this was a reasonable compromise.

2. The proposal in https://w3c.github.io/webappsec/specs/content-security-policy/#source-list-paths-and-redirects is meant to prevent brute-force detection of path information cross-origin, as that risk was way too high to accept.

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