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

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

From: Brian Smith <brian@briansmith.org>
Date: Wed, 19 Nov 2014 16:44:20 -0800
Message-ID: <CAFewVt42ffWV4iYQapajeFRrTDdDPAYyccukHX1QK2=nbOPYog@mail.gmail.com>
To: Devdatta Akhawe <dev.akhawe@gmail.com>
Cc: Joel Weinberger <jww@chromium.org>, 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>
On Sat, Nov 8, 2014 at 8:20 PM, Devdatta Akhawe <dev.akhawe@gmail.com> wrote:
>> Do you have a pointer to an explanation about why it is important for
>> SRI to not be part of CSP?
>
> I don't think SRI should not be part of CSP; I just don't think it
> should be part of CSP exclusively. I don't think anyone has written
> down any reasoning , but let me try list some reasons that I thought
> of right now :)

Last week, I met with Devdatta and he made a good point regarding CSP:
Although the spec doesn't say so, most people expect that CSP will
block a request from ever being made. But, in order to verify a digest
for SRI enforcement, the browser has to make the request and verify
the result. For this reason, it doesn't seem to make sense for SRI to
be part of the CSP source list directive. Do other people agree with
this reasoning? I think it makes sense.

> With stuff like non-canonical-src, there is some security relevant
> sensitive inline with the page still. For example, if the CDN server
> is haxored and there is XSS on the host page, then the CDN server
> could be told return malicious files, the hash (from CSP) won't match
> and the browser will host stuff from non-canonical-src (provided by
> attacker) which again means we are pwned.

It would be very surprising to me for SRI to be defined in such a way
that the non-canonical-src wasn't also subject to the SRI restrictions
in the same way src is, so I don't understand what the problem is.

Also, it isn't clear to me that noncanonical-src is necessary for a
minimal viable product SRI 1.0. I don't see the motivation for it in
the use cases in the current editor's draft. Why not defer it to v2?

The point was also raised that SRI is kind of more fundamental than
CSP, because a properly-functioning website (no XSS vulnerabilities)
should not need to use CSP at all (at least the source list
directives), but a properly-functioning website still benefits a lot
from SRI. So, I agree that it doesn't make sense to block SRI on
improving its integration with CSP.

The most important use case for SRI is making CDNs safer to use, to
help with HTTPS deployment. This is a use case that shouldn't have to
wait for Service Workers. With this in mind, I am surprised that the
current editor's draft cut out support for stylesheets but kept
noncanonical-src for v1. Arguably, it is even more important for
performance to deliver stylesheets from an untrustworthy-but-fast
server than it is to deliver scripts, and the safety concerns are not
too different.

Cheers,
Brian
Received on Thursday, 20 November 2014 00:44:47 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:08 UTC