Re: Remove paths from CSP?

I've (finally) put up a proposal based on this discussion:
https://github.com/w3c/webappsec/pull/18

I ended up with a variant of Egor's suggestion, which boils down to "When
matching URIs against a policy, ignore path components of source
expressions if URI is the result of a redirect."

This proposal does not resolve the detection of google.com -->
accounts.google.com redirection.

I believe it does resolve the brute-forcing of example.com/redirector -->
example.com/sekrit-path.

Comments welcome. :)

-mike

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


On Sat, Mar 1, 2014 at 1:36 AM, Joel Weinberger <jww@chromium.org> wrote:

> Sorry to jump in so late here. From my perspective:
>
>    - Putting scripts on a single domain with other content today is a
>    totally reasonable practice, and getting rid of that would require a vast
>    redesign of complex websites which, in practice, would mean these sites
>    don't adopt a (meaningful) CSP. This is bad for security on the Web. Thus,
>    I consider getting rid of paths a non starter.
>    - Related: In general, the argument that sites should move their
>    scripts to another domain so we don't need paths rings no more reasonable
>    than saying sites should not use redirects on login. Theoretically both are
>    possible, but *both* are onerous and unreasonable.
>    - CSP reporting is a tremendously valuable tool for Web developers in
>    testing CSP before they release it. I've talked to numerous developers
>    who've outlined how they couldn't turn on CSP (or even think of turning it
>    on) without extensively using reporting in the wild. I suppose we could
>    imagine a neutered version of reporting, but I suspect that would also
>    mitigate all of its value. Thus, I also consider getting rid of reporting a
>    non-starter.
>    - That really only leaves one option, which is trying to avoid the
>    problem in the first place. It seems like we're all (pretty much) in
>    agreement that we're talking about testing whether a user is logged into a
>    particular site. Dan Veditz has me pretty convinced that on pretty much any
>    site that isn't plaintext behind the login, you can already test this.
>    Obviously, we want to minimize how much CSP helps attackers in this
>    particular case, but as Michal points out, it's all about tradeoffs.
>
> Thus, baring some deep security issue with it that I'm not seeing, Egor's
> proposal makes the most sense to me and I think that's the way to go. It
> mitigates the problems we're discussing while keeping the current power and
> flexibility of CSP.
>  --Joel
>
> On Fri, Feb 28, 2014 at 2:49 AM, Sigbjørn Vik <sigbjorn@opera.com> wrote:
>
>> On 28-Feb-14 01:52, Oda, Terri wrote:
>> >     Static resources such as images and scripts don't need login
>> protection,
>> >     and can be served identically to logged-in and not logged-in users.
>> >
>> > What about a stock photography site that only wants to provide access to
>> > high resolution, watermark-free images to those who have paid for them?
>> >  What about a games site that only allows logged in users access to
>> > their javascript games?
>> >
>> > It may be true in many cases that images and scripts don't need login
>> > protection, but I don't think it's true in all cases.
>>
>> Agreed. My point is that it is true in many cases, and that in such
>> cases, CSP may enable a security hole on an otherwise secure site.
>>
>> --
>> Sigbjørn Vik
>> Opera Software
>>
>>
>