W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: Proposal: A pinning mechanism for CSP?

From: Mike West <mkwst@google.com>
Date: Sat, 7 Feb 2015 06:27:07 +0100
Message-ID: <CAKXHy=fHjDdMTp81NYLKKqZ-dzXoCFB2_SeDqH=-hDO3Rp=n0A@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, yan zhu <yan@mit.edu>, Chris Palmer <palmer@google.com>, Ryan Sleevi <sleevi@google.com>, Brad Hill <hillbrad@gmail.com>, Dan Veditz <dveditz@mozilla.com>
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. For instance, I just checked
https://mikewest.org/404, a page that _really should_ have a CSP, as it's
terribly high-value, and the guy responsible for it knows a thing or two
about CSP.

I know it's possible to configure nginx to send proper headers with error
pages, but I didn't do it because I never thought about it until just this
moment. I suspect that other (even _more_ valuable sites) are in similar
situations.

Belts and suspenders, right?

In most web servers I've used, it is trivial to configure them to
> either (a) add the same header to every response, or (b) use a default
> value for a header in a response if the header wasn't already set by
> the back end. It seems like we could simply add a recommendation to
> the CSP spec to do this, and be done.
>

We should add that recommendation regardless:
https://github.com/w3c/webappsec/issues/168

The DoS potential of HPKP pinning seems like it would
> apply to CSP pinning too.
>

The worst case HPKP failure is a bricked server, as trust can't be
established at all, not even to kill the pin. A pinned CSP doesn't actually
prevent you from talking to the server, so it remains capable of updating a
bad pin (or disabling pinning entirely via `max-age=0`).


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

--
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 Saturday, 7 February 2015 05:27:56 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:10 UTC