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

I think a future iteration of SRI could certainly tie CSP hashes to SRI
digests, with some syntax that forced both to be present. That is, given:

    CSP: script-src 'sha256-kh....lkhf'

    <script src='http://whatever.com/script.js'
integrity='ni:///kh...lkhf'> <!-- loads! -->
    <script src='http://whatever.com/script.js'> <!-- doesn't! -->

-mike

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

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

On Wed, Oct 29, 2014 at 6:37 AM, Brian Smith <brian@briansmith.org> wrote:

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