W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2016

Whitelisting external resources by hash (was Re: Finalizing the shape of CSP ‘unsafe-dynamic’)

From: Mike West <mkwst@google.com>
Date: Tue, 7 Jun 2016 15:13:43 +0200
Message-ID: <CAKXHy=enNk6T1O-3y9k4UcX_3iYr5TpVm6AAemUm59qjxmyPyQ@mail.gmail.com>
To: Artur Janc <aaj@google.com>
Cc: Devdatta Akhawe <dev.akhawe@gmail.com>, Brad Hill <hillbrad@gmail.com>, WebAppSec WG <public-webappsec@w3.org>, Christoph Kerschbaumer <ckerschbaumer@mozilla.com>, Daniel Bates <dabates@apple.com>, Devdatta Akhawe <dev@dropbox.com>
> While we're on the topic, I'd like to harden that example via externalized
>> hashes (e.g. `sha256-abc...` would allow `<script integrity="sha256-abc..."
>> ...>` to load). I'd like to find a mechanism to do so in a backwards
>> compatible way. We discussed it briefly at our last meeting. Anyone have
>> any good ideas? :)
> To properly discuss it, I'd suggest doing it on another thread, maybe? ;)

Done. :)

> FWIW my preference would be to allow hashes to whitelist script URLs
> rather than contents, and keep SRI as a mechanism to enforce integrity...

What do you mean by "allow hashes to whitelist script URLs"? Adding
`SHA256("https://example.com")` to a policy to match a resource at "
https://example.com"? I don't see any advantage to doing so (other than
policy length, I suppose?).

> Otherwise, the "static content" case will be difficult to achieve with
> hashes because any changes to the external scripts will break the policy,
> since the digest will no longer match.

I'd like to tie the CSP implementation to the SRI implementation. If/when
SRI2 supports something other than flat content matches (signatures, etc),
then CSP would flow right along.

As long as we have SRI that supports the brittle kind of loading behavior
that you note above (which I do believe is valuable, though I recognize its
drawbacks), it makes sense for CSP to have the same behavior.

Received on Tuesday, 7 June 2016 13:14:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:56 UTC