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

+1 to allowing a hash on external resources (and/or setting up that to be a requirement) . . 

Trusting a CDN generally speaking is no different than trusting any other 3rd-party URI/origin, and I thinkby allowing CSP to define required hashes/signatures for external resources that would be helpful.
However, I'd also want to suggest that in doing so, you'd want to set that up to be mime-type driven,and URI/origin driven.  For example, I probably don't care if some random image tag gets loaded
in a given document. . .but I do care about script (or potentially IFRAMEs, or whatever).
Sean
      From: Joel Weinberger <jww@chromium.org>
 To: Hatter Jiang OWS <hatter@openwebsecurity.org> 
Cc: Ben Toews <btoews@github.com>; Mike West <mkwst@google.com>; Brian Smith <brian@briansmith.org>; Frederik Braun <fbraun@mozilla.com>; "public-webappsec@w3.org" <public-webappsec@w3.org> 
 Sent: Wednesday, October 29, 2014 8:27 AM
 Subject: 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 86891Sitz der Gesellschaft: HamburgGeschä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