Re: Proposal: A pinning mechanism for CSP?

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