- From: Yan Zhu <yzhu@yahoo-inc.com>
- Date: Fri, 23 Jan 2015 20:29:55 +0000 (UTC)
- To: Mike West <mkwst@google.com>, Brad Hill <hillbrad@gmail.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>
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 13:23:55 UTC