W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2014

Re: [SRI] To trust or not to trust a CDN

From: Joel Weinberger <jww@chromium.org>
Date: Tue, 28 Oct 2014 17:23:07 -0700
Message-ID: <CAHQV2K=1cYxDwd6A6dLFdvvOe-a4_a9B6jJ5bL5+yHJDrnbTLQ@mail.gmail.com>
To: Frederik Braun <fbraun@mozilla.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Tue, Oct 28, 2014 at 1:02 PM, Frederik Braun <fbraun@mozilla.com> wrote:

> Subresource Integrity is supposed to help not having to trust CDNs. The
> idea is that a compromised JavaScript library on another origin can not
> harm the web page. This is in contrast to CSP having to trust the whole
> origin.
> If I want to use CSP I am saying "I trust this whole origin". If I want
> to use SRI I say "I do not trust this origin, but that file is fine".
> With SRI in place means we will put an untrusted origin (it's untrusted
> - otherwise we wouldn't use SRI?) into the CSP whitelist. Meaning that
> every file from this untrusted origin is fine.
Not necessarily. With paths in CSP, it's certainly possible that you'd only
list the one file.

> This is a weird contradiction. Assuming XSS and thinking the CDN may
> indeed become evil, an attacker may just include <script
> src="https://cdn.example/evil.js"> instead of <script
> src="https://cdn.example/lib.js integrity=valid> and it will work :(
I don't see this as a contradiction at all. Perhaps a better way to
describe CSP and SRI is:
   * CSP is for protecting your web application from client-side compromise
   * SRI is for protecting your web application from third-party server

More specifically, SRI has nothing to do with client compromise. If your
client is compromised, you're sad, and there's nothing to be done.

> I wonder if this may be solved with CSP hash-src, though hash-src is
> only for inline scripts, not other-origin scripts.
> Maybe because of the privacy concerns that this would allow learning the
> hash of cross-origin resources?
> This would require CORS-enabled (just like SRI) then.
Received on Wednesday, 29 October 2014 00:23:34 UTC

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