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

A lot of CDNs host assets under a subpath instead of on a subdomain. This
makes CSP harder to implement because an attacker can host JavaScript on a
trusted domain. Like Frederik mentions the attacker can also then inject
script tags then without an integrity attribute. I'd love it if script-hash
worked on remote scripts or if SRI could be specified with a header.

On Wed, Oct 29, 2014 at 8:26 AM, Mike West <mkwst@google.com> wrote:

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