Re: Proposal: A pinning mechanism for CSP?

Mike West <mkwst@google.com> writes:

> Based on this conversation, I've relaxed the proposal to cover only those
> cases where a `Content-Security-Policy` header is not present in a
> response. That covers the majority of what I wanted in a pinning solution.
>
> It wouldn't be difficult to change the behavior to an overlay rather than a
> default, either from an implementation perspective or a spec perspective. I
> suspect that the danger of policy-based suicide is limited, as the author
> can always send a `max-age 0` to remove the bad policy. This is distinct
> from the PKP case, where the pinned key actually prevents _connection_ to
> the source which could expire the pinned policy.
>
> I think it will be worth adding a `no-override` flag in the future, once we
> hash out the threat model it defends against in a clear way.
>
> For the moment, I think the drafted proposal solves a real gap in current
> implementations, and does so in a pretty straightforward way.
>
> Perhaps you folks at AppSec can chat today to see if there are fundamental
> objections I haven't considered? If not, I'd like to republish the draft as
> a WebAppSec product (rather than as a "collection of interesting ideas"
> under Google's copyright), and see if we can agree to push it out as a FPWD.

Wish I was at AppSec to hear the discussion :)

Instead of overriding the pinned policy with the header-supplied policy,
have you considered treating the pinned policy as a base policy and
requiring the CSP header to provide an `override-base` directive to
override the pinned policy? (I don't think that this is incompatible
with `no-override`.) This clearly favors security over deployability,
but I'm curious to hear if there was any discussion about this.

Thanks,
Deian

Received on Friday, 30 January 2015 05:45:55 UTC