Re: Proposal: A pinning mechanism for CSP?

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!
>