Re: Proposal: A pinning mechanism for CSP?

-trimming the CC list, +Alex for the ServiceWorker path question below.

On Wed, Feb 11, 2015 at 10:40 PM, Brian Smith <brian@briansmith.org> wrote:
> 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.

I don't really understand that decision. +Alex, who likely has opinions.

> Also, includeSubdomains crosses the origin security boundary.

Indeed. But owning `example.com` is a pretty good indication that you
have control over `*.example.com`. This is especially true if we take
the PSL into account.

I'd justify crossing the origin boundary here by noting that
subdomains can act as their parent domains via `document.domain`, and
cookies cross the origin/host boundary with abandon. Given that we
wish to protect against abuse of both, allowing explicitly pinned
policies to take effect over that boundary seems reasonable.

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

Start a new thread! Threads are cheap. :)

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

I'm trying to find a balance between coming to the group with a
finished solution, looking for a rubber interoperability/patent
protection stamp, and coming to the group with unformed ideas, looking
for guidance. I think that being a good standards citizen means ending
up somewhere in the middle, but I'm not sure I'm doing a good job of
that here.

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

My claim is that helping servers define policies that they should
already be enacting on their own is a huge chunk of what CSP is all
about. I think we'd agree that escaping is, technically, a solved and
trivial problem. There are ~5 contexts in HTML. The rules for each
context are well known. XSS should be a non-problem at this point. The
fact that it isn't, even at large, well-funded companies with huge
security staff, goes some way towards proving that server operators
need help.

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

I bet a typical server would cover +80% of its users by only sending a
pin on the landing page, but yes, in general we'd want to suggest that
both headers be sent.

Typing that, it occurs to me that we could model pinning as a
directive rather than a new header, which would reduce header bloat.
Hrm. That would be a lot less flexible, as you'd need to apply the pin
to the page on which it was delivered, which would make it hard to
have a really locked down `default-src 'none'` style pin, but it might
be worth exploring...

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

I would like more people to share their ideas here. You, for instance.
In that other thread I mentioned earlier. :)

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany,
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine
Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Received on Thursday, 12 February 2015 08:04:52 UTC