W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2015

Re: Proposal: A pinning mechanism for CSP?

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>
Message-ID: <828348839.222582.1422044995264.JavaMail.yahoo@mail.yahoo.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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:09 UTC