W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2014

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

From: Brian Smith <brian@briansmith.org>
Date: Thu, 30 Oct 2014 17:44:51 -0700
Message-ID: <CAFewVt4GJcVy80vs-kr2FxgpPkvfd5yD=nWF+L=LS67Gv-nhLQ@mail.gmail.com>
To: Joel Weinberger <jww@chromium.org>
Cc: Hatter Jiang OWS <hatter@openwebsecurity.org>, Ben Toews <btoews@github.com>, Mike West <mkwst@google.com>, Frederik Braun <fbraun@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
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.

Received on Friday, 31 October 2014 00:45:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:42 UTC