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: Mon, 9 Feb 2015 09:42:32 +0100
Message-ID: <CAKXHy=dqvVVzrwVrJz9TviDFzgBeyiKdLvsLAHHbd-XE1Pumog@mail.gmail.com>
To: Eric Mill <eric@konklone.com>
Cc: Brian Smith <brian@briansmith.org>, "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 Sat, Feb 7, 2015 at 4:38 PM, Eric Mill <eric@konklone.com> wrote:

> The thought this brought to mind was that it'd be best done at the server
> _proxy_ level, a bit like Google's page_speed module. For example, a
> CloudFlare switch might use it to rewrote the page to use static resource
> links before caching it at their edge nodes.
>

Yes. I agree that this is something the page_speed team (and other, similar
products) ought to be looking into. The general issue with middleware,
however, is that it doesn't understand which pieces of your site are
intentionally loading script, and which scripts have been maliciously
injected. That is, page_speed will be hard-pressed to prevent XSS attacks
in the same way a pinned policy could.


> That wouldn't cover dynamic references, like XHRs triggered from
> JavaScript -- but that's fine, because HSTS _will_ cover those.
>

I think we're mixing conversations here. Brian's comment was focused on
pinning a CSP for a site which didn't otherwise send a
`Content-Security-Policy` header. The other set of threads is focused on
upgrading first- and third-party resource requests. :)

-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.)
Received on Monday, 9 February 2015 08:43:20 UTC

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