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

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