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

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.

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.

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.

Cheers,
Brian