Re: Proposal: A pinning mechanism for CSP?

Mike West <mkwst@google.com> wrote:
> On Mon, Feb 9, 2015 at 1:47 PM, Brian Smith <brian@briansmith.org> wrote:
>>
>> Consider a resource https://example.com/mallory/foo. Why would it make
>> sense to allow that resource to set a Content-Security-Policy-Pin
>> header field that would apply to https://example.com/alice/bar, when
>> we don't let it install a ServiceWorker that applies to
>> https://example.com/alice/bar or even other suborigins of example.com?
>
> The origin is the only sensical security boundary we have. It's not clear to
> me how `/alice` is at all protected from `/mallory`

First, I personally agree 100%. But, wasn't this already decided
differently for ServiceWorkers? It seems to me that the security
concerns are very similar. Perhaps the solution is to undo the special
treatment for ServiceWorkers.

Also, includeSubdomains crosses the origin security boundary.

>> Consider, for example "Content-Security-Policy-Pin: includeSubdomains;
>> referrer unsafe-url; reflected-xss allow; report-uri ". Now
>> https://example.com/mallory/foo has weakened the privacy/security of
>> all subdomains of example.com and of the content managed by user
>> Alice.
>
> Assuming Mallory has the ability to inject headers, yes, she could do that.
> But she owns the origin at that point, doesn't she?

I'll assume we agree that the origin is the boundary of trust. In this
case, mallory may own example.com, but she doesn't own the subdomains,
necessarily.

> (Also, is 'allow' really scarier than 'filter'? Didn't you argue the
> opposite in that other thread I haven't responded to yet? :) )

I personally think so, but I thought "allow" would illustrate this
point more clearly.

>> > Belts and suspenders, right?
>>
>> 1. As I mentioned above, it isn't just a matter of
>> belts-and-suspenders, because the mechanism itself has some quite
>> negative security implications.

> If you don't accept that argument, and you think it's really the case that
> `referrer`, `reflected-xss`, and `report-uri` are too powerful to pin,
> consider a variant of the proposal which excludes them (and the
> `-report-only` variant). Would you still have the same concerns?

Regarding the security issues: no.

However, I still question the value proposition and cost/benefit of
this specific mechanism. More on this below.

>> 2. I am uncertain why pinning CSP should be a high priority relative
>> to other possible work in the working group.
>
> You've mentioned this sentiment two or three times now in different threads;
> are there specific things that you think the WG is ignoring at the moment
> that we should concentrate on fixing?

In general, I think it would be good for the working group to
concentrate on things that cannot be solved solely with better
server-side tools. I'm unenthusiastic about CSP pinning (and EPR)
because it can be done server-side. If people are interested in what I
think are the highest priority items, I am willing to share that too,
but I think that's a little too far off-topic for this thread.

>> In particular, if it can already be done simply in the web
>> server/framework configuration file, then it seems like a low priority
>> to define a new pinning mechanism to act as a substitute for doing
>> that.
>
> First, low priority != no priority. Brad noted in
> https://lists.w3.org/Archives/Public/public-webappsec/2015Jan/0329.html that
> at least Facebook would be interested in this kind of feature. Publishing a
> WD to widen the net seems like a good way of determining whether or not this
> kind of thing has legs.

I don't know how the working group works, exactly. My expectation is
that the "determining whether or not this kind of thing has legs" step
should occur before adoption of the thing as a work item.

My argument is that there are lots of things the server has to do
correctly for every request and for every response. It seems futile to
try to add mechanisms to browsers to compensate for servers forgetting
to do those things. Cache-Control/max-age is an even more serious
example of things servers already have to do correctly, and that many
get wrong by omission. Having a special mechanism to deal with omitted
Content-Security-Policy header fields just doesn't seem to make sense
to me within the context of that overall problem.

Also, logically, is is almost as important for every resource from a
server to send the correct Content-Security-Policy-Pin header field as
it is for it to send a Content-Security-Policy header field without a
pinning mechanism, right?

Anyway, I didn't intend to be a wet blanket or to discourage you from
sharing your ideas here.

I think it would be great to get feedback from more people on the
idea, especially the actual members of the working group.

Cheers,
Brian

Received on Wednesday, 11 February 2015 21:40:57 UTC