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

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

From: Brian Smith <brian@briansmith.org>
Date: Tue, 28 Oct 2014 22:37:03 -0700
Message-ID: <CAFewVt7gXNGc00zZheusF_vYHSZ=1HY1=sqWBjqxi45F=6Nj6g@mail.gmail.com>
To: Joel Weinberger <jww@chromium.org>
Cc: Frederik Braun <fbraun@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Joel Weinberger <jww@chromium.org> wrote:

> On Tue, Oct 28, 2014 at 1:02 PM, Frederik Braun <fbraun@mozilla.com>
> wrote:
>
>> 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.
>

I suspect that for usability reasons, most websites are going to have
pretty course-grained CSP policies, whitelisting whole domains or fairly
non-specific path prefixes.


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

I mostly agree with your classification. But, I also agree with Frederik
that it seems strange that there's no way to combine SRI with CSP while
honoring the principle of least privilege.

Consider this:

    Content-Security-Policy: script-src http://example.com/foo.js

    <script src='http://example.com/foo.js' integrity='ni:[digest]'>

    <script src='http://example.com/foo.js'>

The first <script> is an intended part of the page. The second script is
injected with XSS. Thus, an XSS attack is able to undo the protection of
SRI even when CSP is in place, and there is nothing you can do about it
with CSP, *even* if you use a full path. That seems wrong. On the other
hand, your server-side development framework should never have let the XSS
happened in the first place, and CSP is the last line of defense, not the
first.

Cheers,
Brian
Received on Wednesday, 29 October 2014 05:37:31 UTC

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