Re: Remove paths from CSP?

So even that CSP detection is not an only way to detect redirects, it's the
most reliable i know so far. Others are heavily timing-based and work
slower, thus internal redirects detections should be mitigated anyway.

My proposal was that CSP: http://example.org/exact/path allows all
subsequent redirects on /exact/path, but CSP: http://example.org doesn't.

It will fix logins / user ID detections on the biggest part of websites,
except cross domain redirects, and won't introduce new weaknesses. Nobody
proposed more backwards-compatible trick to fix the issue (did I miss it?)


On Sat, Mar 1, 2014 at 7: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
>>
>>
>


-- 
Consulting: http://www.sakurity.com/
@homakov <https://twitter.com/homakov>