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

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
compromise

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