Re: Proposal: A pinning mechanism for CSP?

Mike West <mkwst@google.com> wrote:
> On Fri, Feb 6, 2015 at 7:14 PM, Brian Smith <brian@briansmith.org> wrote:
>> Isn't this better done as a feature of web servers than a feature of
>> web browsers?
>
> It's certainly something that could be done as a feature of web servers.
> However, it's really easy to miss pages.

<snip>

First, let's consider something I think is problematic about the
mechanism proposed in the csp-pinning document:

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?
Is it because CSP is a purely restrictive security mechanism? But, at
least with referrer and reflected-xss as they are recommended now,
it's not purely restrictive. And with report-uri, there are potential
exfiltration issues, I think.

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.

In general, this type of problem should be less likely to happen if
default policy is simply managed using the front-end(-ish) web
servers' configuration.

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

2. I am uncertain why pinning CSP should be a high priority relative
to other possible work in the working group. (No doubt part of this
uncertainty is due to me not being fully clued into what motivated
it.) 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.

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

Cheers,
Brian

Received on Monday, 9 February 2015 12:47:51 UTC