- From: Brad Hill <hillbrad@gmail.com>
- Date: Mon, 26 Jan 2015 06:26:46 +0000
- To: Yan Zhu <yzhu@yahoo-inc.com>, Mike West <mkwst@google.com>
- Cc: Jim Manico <jim.manico@owasp.org>, Frederik Braun <fbraun@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, yan zhu <yan@mit.edu>, Chris Palmer <palmer@google.com>, Ryan Sleevi <sleevi@google.com>, Dan Veditz <dveditz@mozilla.com>
- Message-ID: <CAEeYn8j=Xos1snKDxN1GtwQoV35v5AUN3WeKbygRzE-Htn_ffQ@mail.gmail.com>
I think that's a very interesting feature proposal. I'm not sure it belongs in CSP, vs an extension to the HPKP grammar or a standalone header? I can see it if I squint, but for reasons I've suggested, I think there are lots of sharp edges for pinning when applied to everything else CSP does. On Sun Jan 25 2015 at 7:57:01 PM Yan Zhu <yzhu@yahoo-inc.com> wrote: > The use case I had for non-overrideable pinning only makes sense if there > is a future CSP directive that says something like, "Do not load any > resources on this page except from a package signed by this key." Suppose > https://securedrop.my-news-site.com (a site where users can go to submit > encrypted messages to journalists) looks like this: > > > <html> > <head> > <link rel="package" href="/securedrop-app.pack" scope="/" > type="application/package"> > </head> > ... > </html> > > where 'securedrop-app.pack' is of the format defined in > https://w3ctag.github.io/packaging-on-the-web/ and includes a digital > signature. The site operator delivers a CSP header that says, "do not load > any resources except from a package signed by [some signing key]" which is > pinned for 3 months. > > With this particular pinned header, the only bricking risk is if the site > loses control of its package signing key; in the analogous case for > installable apps/extensions, they're are out of luck too. > > The threat model here is that most users should be safe even if the server > delivering code updates is compromised. > > I realize this is a stretch since that threat scenario was never in scope > for CSP, but I just wanted to throw it out there since it's something that > multiple projects seem interested in. > > Thanks, > Yan > > On Friday, January 23, 2015 1:57 PM, Brad Hill <hillbrad@gmail.com> wrote: > > > > There is a lot of tension here between preventing pin-suicide (as > cryptocat has already done with key pinning) and a somewhat dubious threat > model - attacker can inject arbitrary headers and code, but we think this > will somehow save users. > > > I'd like to see more exploration of the latter threat model to be > convinced it makes sense, and also to understand what kind of measures > would be needed to mitigate deployment risk. > > I too, started with a policy like you suggest for an experiment I'm > working on, then I needed ReCAPTCHA, then I found there were bugs in > Chrome's policy enforcement on iOS, and I needed to update my policies to > make things work. I think that CSP in deployment for real apps tends to be > either static and report-only or very loose, or meaningfully strict to > offer serious preventative control and highly evolving. > > Chrome apps have a manifested policy that looks like a pin, but you can > update it by updating the app. How do you update the CSP pin for a webapp? > > On Fri Jan 23 2015 at 12:30:44 PM Yan Zhu <yzhu@yahoo-inc.com> wrote: > > On Friday, January 23, 2015 11:23 AM, Mike West <mkwst@google.com> wrote: > > > > > >>On Fri, Jan 23, 2015 at 7:29 PM, Brad Hill <hillbrad@gmail.com> > wrote:>>>The pinning model in the proposal uses the existing > >>>> combination logic for multiple headers: resources simply > >>>> need to pass all the policies applied to a protected resource. > >>>> I think overriding the pinned policy completely would undermine > >>>> its impact to some extent; I'd prefer to avoid doing that unless > >>>> there's a good reason to. > >>> > >>> > >>> > > > >>>I don't know about that. I like the idea of "here's a backup policy in > case things go wrong and >>we forget to send one". For example, if an > application ends up returning an error page before the >>logic that applies > the policy was reached.> > > > >> I hadn't thought about the problem this way; it's a compelling > alternative, mostly because it > > > >> reduces the deployment risk to (practically) nil.> > > > >> The overall concept, then, would be "Every page on my host(s) MUST have > a Content Security > >> Policy.", which is similar conceptually to HSTS's promise that every > page on a host will be > >> delivered over HTTPS. I think it's worth exploring (sorry, Jim; I > shouldn't have dismissed the > >> idea so quickly).> > > > >> I don't want to entirely give up the stricter "Every page on my host(s) > MUST have a CSP that's at > least this strict." variant. I think Yan had > some use cases that would benefit from that sort of > >> promise. Perhaps we can do both with something horrible like a > `no-override` directive? > > > >My main use case was web apps that are infrequently updated and need to > make especially strong security guarantees to users (like SecureDrop, > CryptoCat, Google/Yahoo's End to End project, etc.). These tend to be > implemented as browser extensions or installable packaged apps, partly due > to lack of something like CSP pinning [1]. > > > > > >For instance, https://cryptomail.example.com (an encrypted webmail > service) might deliver the following non-overrideable CSP pin header: > > > >"Content-Security-Policy-Pin: default-src 'none'; script-src 'self'; > style-src 'self'; max-age=31536000; includeSubDomains" > > > >because the developers want to ensure that if a cryptomail server is > temporarily compromised, the attacker will not be able to start loading > inline scripts or malicious third-party content by suddenly changing the > headers. (This doesn't stop them from loading malicious first-party > scripts, but I'm hoping to get code signing into SRI or the TAG's proposed > packaging format to deal with that.) > > > >The no-override directive doesn't sound like such a bad option to me. :) > > > > > >[1] Chrome extensions enforce a strict CSP policy by default and lets > developers "pin" policies in the extension manifest file: > https://developer.chrome.com/extensions/contentSecurityPolicy. > > > > > > > >> Also, if we allow overrides at all, I'd suggest that `<meta>`-delivered > policies shouldn't > >> override pinned policies. That seems like a bad idea. > > > >Agree! > > >
Received on Monday, 26 January 2015 06:27:46 UTC