- From: Egor Homakov <homakov@gmail.com>
- Date: Sat, 1 Mar 2014 09:46:49 +0700
- To: Joel Weinberger <jww@chromium.org>, public-webappsec@w3.org
- Message-ID: <CAMQFCuj0OkZG4dqYqvUB7j=sZCatC68hTzonK2MSOB4sy5U4+g@mail.gmail.com>
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>
Received on Saturday, 1 March 2014 02:47:17 UTC