W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2014

Re: Remove paths from CSP?

From: Joel Weinberger <jww@chromium.org>
Date: Fri, 28 Feb 2014 16:36:31 -0800
Message-ID: <CAHQV2Kk9tMRmU-Pdete7BENJH9=0VRd2YZb_Stp+sM4L2JZzjA@mail.gmail.com>
To: Sigbjørn Vik <sigbjorn@opera.com>
Cc: "Oda, Terri" <terri.oda@intel.com>, Michal Zalewski <lcamtuf@coredump.cx>, Mike West <mkwst@google.com>, Dan Veditz <dveditz@mozilla.com>, Egor Homakov <homakov@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, "Eduardo' Vela" <evn@google.com>
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
   - 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.

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
Received on Saturday, 1 March 2014 00:36:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:37 UTC