Re: Proposal: A pinning mechanism for CSP?

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`


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

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

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

As noted above, those implications require you to be able to inject headers
into responses from the origin. At that point, it's not clear to me that
you're readily distinguishable from someone who owns the origin and can
already do bad things to its users.

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?


> 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? *shrug* I'm throwing the ideas
that I have at the wall to see what sticks. I wish I had more ideas to
throw, but this is what I've got right now. I blame child-based sleep
deprivation. ;)

In short, I would love to see _more_ people proposing _more_ things on the
list and elsewhere. I think we collectively should be moving _much_ faster
on a _large_ number of topics. CSP pinning is certainly not the most
important thing ever, but I don't think that publishing a WD on that topic
prevents us from working on other topics that are nearer and dearer to your
heart.


> (No doubt part of this uncertainty is due to me not being fully clued into
> what motivated it.)


Some of the motivation was Yan's use case that's now been punted to
https://lists.w3.org/Archives/Public/public-webappsec/2015Jan/0307.html.
Some more of the motivation was seeing some attacks on Google error pages
that would have been prevented if we had a) sent the right headers in the
first place, or b) pinned something like `frame-ancestors 'none';
script-src 'none'; object-src 'none'`.

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.

Second, relying on folks to do the right thing on the server side has,
historically, proven to be ineffective at preventing issues from occurring.
Taken to it's slippery extreme, we don't really need to do CSP, because we
can simply escape data correctly before outputting it, right?

It seems fairly well in-line with CSP's general goals to specify a
mechanism of asking the user agent to help out by locking in particular
configurations that the server really could do all by itself, but doesn't
trust itself to do perfectly. Being perfect is hard. It shouldn't be a
requirement.


> >> Considering that there's already a
> >> way to accomplish this with existing tools, and considering there are
> >> (IMO) more important WebAppSec problems to solve (e.g. <script
> >> src=http://third-party.example.com/insert-widget.js>)
> >
> > What's the problem to solve in this example?
>
> I started a new thread on this, regarding iframe sandbox.
>

Thanks! That's a discussion well worth having. I hope we can use it to
prove the point that discussing pinning doesn't stop us from discussing
other things too. :)

-mike

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