Re: Proposal: A pinning mechanism for CSP?

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