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

Joel Weinberger <jww@chromium.org> wrote:

> On Thu, Oct 30, 2014 at 5:44 PM, Brian Smith <brian@briansmith.org> wrote:
>
>> Joel Weinberger <jww@chromium.org> wrote:
>>
>>>
>>>>>> 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.
>

I guess we're just arguing about degrees. But, the threat model for SRI is
that example.com will attack you if you don't use SRI. In other words, it
isn't a matter of *if* the attacker controls example.com, because with SRI
you assume that the attacker controls example.com. Doing s/
example.com/really-fast-but-dishost-cdn.com/ makes this clearer.


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

I don't think this is a matter of nature. It's purely a function of the
chosen syntax for SRI. A different syntax for SRI (more like CSP) wouldn't
have this problem. This indicates to me that we should try a CSP-like
syntax.


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

CSP vs. attribute syntax is a false dichotomy. SRI could also be its own
header, for example.


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

If you have script-hash in your CSP then you wouldn't need the SRI
attribute to get the protection of SRI. I think it is better to have one
syntax for SRI instead of two, and the attribute syntax seems unworkable as
the only syntax, so I think we should consider replacing it.

In particular, I could see having a SRI header like this:

SRI: https://example.com/a.js ni://<as-currently-specified>,
https://example.com/b.js ni://<as-currently-specified>

Imagine a use case like a Twitter timeline, where the same image is
repeated multiple times. This syntax would enable you to specify the hash
only once, instead of every time. Also, this syntax would also work for CSS
and other places where URLs are used outside the HTML element/attribute
syntax.

Alternatively, I don't really see too much of a problem with making SRI
part of CSP. It actually seems like a more natural part of CSP than some
parts of CSP do (e.g. "referrer").

Cheers,
Brian