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

On Wed, Oct 29, 2014 at 7:30 AM, Hatter Jiang OWS <
hatter@openwebsecurity.org> wrote:

> Is it possible use signature in SRI:
>
> <script src="https://cdn.example.com/some.js"
>
> integrity="key:///rsa;public-key-in-base64?ct=application/javascript">
>
> The resource should contain a header name: Content-Signature like
> http://tools.ietf.org/html/draft-burke-content-signature-00
>
> The user agent just verify the resource use RSA public key.
>

>
> On Wed, Oct 29, 2014 at 5:08 PM, Ben Toews <btoews@github.com> wrote:
>
>> 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.
>>
>> If I understand you correctly, then the fact that CSP allows subpaths
makes us happy in this case (and is the reason we added this to the
standard).

> 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.
>>>>
>>> Meh, if we give sites the power (path based CSP whitelisting), and they
fail to utilize it and are hacked, my sympathy is limited. I'm not too
concerned with XSS on sites using unsafe-inline for the same reason.
Perhaps we should make an explicit recommendation in the standard,
html5rocks, etc that if using a CDN or other shared domain to host content,
you should strongly consider path based whitelists?

>
>>>>
>>>>>
>>>>>> 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'>
>>>>
>>> We're talingk about a two attacks on two applications that need to occur
for all of this to work. That is, if I just compromise example.com, all I
can do is modify foo.js, which the integrity check blocks. If I compromise
the client app (let's call it bar.com) with an XSS, I can inject an
integrity-less link to foo.js... but that's only concerning if I *also*
compromised example.com.

Sure, I agree it would be nice to stop this, but that's pretty darn
specific at this point. Am I a missing another attack here?

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