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

On Thu, Oct 30, 2014 at 5:44 PM, Brian Smith <brian@briansmith.org> wrote:

> Joel Weinberger <jww@chromium.org> wrote:
>
>> On Wed, Oct 29, 2014 at 6:37 AM, Brian Smith
>>>>>
>>>>>> 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?
>>
>
> So, nobody should use anything other than full paths in CSP anymore, and
> every page should have a custom CSP? I think that, for usability reasons,
> people will find that too limiting.
>
No, but if you whitelist a full domain, you whitelist a full domain. In the
proposal, you'd be whitelisting a path anyway; the request is just that
you'll put the path in script-src. So we're really just arguing over where
you put the path.

>
> 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.
>>
>
> The assumption with SRI that the attacker *is* example.com, right?
> Because of the CORS stuff, the attacker (example.com) can choose to
> return the expected resource for SRI-enabled requests while sending
> malicious content for non-SRI-enabled requests. Thus, one of those two
> attacks is trivial, and therefore the "two attacks" mostly boil down to a
> single XSS.
>
No, that wouldn't work, because if the attacker controls example.com (the
CDN) but does not have an XSS on bar.com (the site that's being loaded),
then any changes to example.com will be rejected because it will fail the
integrity check. The only way this works is if you have an XSS on bar.com
as well, which means two separate attacks (one on the example.com server
and an XSS at bar.com). So, yes, if an attacker both (a) controls
example.com, and (b) has an XSS at bar.com, then you're sad. But that's a
pretty high bar.

It is an interesting point, though, that SRI is pretty much useless if you
load one resource from a site with integrity and one site without
integrity, but that's just the nature of the beast (and really no different
from CSP; if you load a page without CSP, it doesn't matter if you have CSP
on the other pages at the same domain).

>
> 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?
>>
>
> In talking with people interested in SRI, they ultimately want to get to
> the point where they can use a truly untrustworthy CDN, at least for
> scripts and other resources that aren't personalized. Like, imagine that
> the CDN's hostname resolves to a server that is is actually *within* the
> coffee shop in Syria you are currently in.
>
> I would normally agree that this isn't something that needs to be solved
> right now (I even suggested so in my original message), but I think it has
> important ramifications for the syntax of SRI. In particular, if you accept
> XSS as a possible attack vector against SRI, then that means that the SRI
> integrity information should be protected similarly to the way CSP policies
> are protected--e.g. outside the document body, in an HTTP header. That is
> the kind of change that is better to make now, rather than trying to
> retrofit it later.
>
I don't see any escaping the attribute syntax, since I think we want to
allow use of the integrity attribute without any CSP at all, so we're
really talking about some additive anyway. This fits in with the CSP model
anyway, which generally has been restrictions on already existing
capabilities. There does seem to be a relatively straightforward path on
how to address this in CSP (using script-hash) if we want to go this way in
the future; I just feel that we shouldn't deal with it right now since we
don't even know if people will use SRI at all.

>
> Cheers,
> Brian
>