W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2015

Re: [CSP] "sri" source expression to enforce SRI

From: Richard Barnes <rbarnes@mozilla.com>
Date: Tue, 22 Dec 2015 14:22:34 -0500
Message-ID: <CAOAcki-cP-8SAR3Ktb4ohWUi5PVJqTtALpm-4nbZJ1m9biaSfQ@mail.gmail.com>
To: Patrick Toomey <patrick.toomey@github.com>
Cc: Joel Weinberger <jww@chromium.org>, WebAppSec WG <public-webappsec@w3.org>
Some sort of "must-sri" directive is something we had considered inside
Mozilla for some of our properties, so this does seem like a productive
thing to look at.  I don't have any personal biases about how exactly to
express it.

On Tue, Dec 22, 2015 at 12:07 PM, Patrick Toomey <patrick.toomey@github.com>

> Yeah, a separate directive probably makes sense. I was originally thinking
> it fit into the "locations that are safe" pattern since we are stating that
> a location is only safe if it has a known hash (using SRI) from that
> location. But, I realize that is a stretch. And, you have a good point
> about being able to put other SRI related things in if we have a separate
> directive. So, yeah, that is probably the cleaner way to go. Thanks for
> opening the tracking issue.
> On Tue, Dec 22, 2015 at 9:32 AM Joel Weinberger <jww@chromium.org> wrote:
>> That's a good point about SRI in general; it's hard to know if you've
>> forgotten to SRI anything. I'm not sure source-expression is the right
>> place to put it in CSP, though, as that's meant to be "locations that are
>> safe," and that's not exactly what you're requesting. It probably makes
>> sense to have an 'sri-options' directive, though, since we'll probably want
>> SRI 'report-only' eventually anyway.
>> I've filed this as a feature request in GitHub, too:
>> https://github.com/w3c/webappsec-subresource-integrity/issues/23
>> --Joel
>> On Tue, Dec 22, 2015 at 2:50 AM Patrick Toomey <patrick.toomey@github.com>
>> wrote:
>>> We recently deployed subresource integrity across GitHub.com:
>>> https://github.com/blog/2058-github-implements-subresource-integrity.
>>> However, a few days after deployment we determined that one of our JS
>>> scripts did not have an "integrity" attribute assigned to it. It was our
>>> intent to add the integrity attribute to all subresources on GitHub.com. We
>>> statically vendor in all CSS/JS and use Sprockets (SRI support was added in
>>> https://github.com/sstephenson/sprockets/pull/645) to package these
>>> assets for production deployments. There happened to be one JS file that
>>> had not been vendored, and hence was not being packaged by Sprockets. This
>>> violated two of our goals:
>>> * Not allowing any dynamically sourced JS (we vendor everything to
>>> ensure what is in version control is what is used in production)
>>> * Enforcing SRI on all supported subresources on GitHub.com
>>> Reflecting back on this situation, it would have been nice to have
>>> support in CSP for a source expression such as
>>> "sri"/"sri-only"/"sri-naming-things-is-hard" to ensure SRI is being used
>>> everywhere. In the above scenario, the related JS would have failed to load
>>> and we would have identified both of the issues listed above in testing.
Received on Tuesday, 22 December 2015 19:23:03 UTC

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