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


Yeah. I guess that does cover the case I described.

On Wed, Oct 29, 2014 at 4:27 PM, Joel Weinberger <jww@chromium.org> wrote:

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