Re: [SRI] require-sri-for: missing integrity metadata? same-origin loads?

On Fri, Sep 9, 2016 at 12:19 AM, Frederik Braun <fbraun@mozilla.com> wrote:

> Hi list,
>
> the SRI editor's draft defines an experimental CSP directive
> "require-sri-for" that is followed by tokens (script or style)[1] to
> mandate that the web page requires integrity metadata or for those
> loads. It was added in this pull request[2]
>
> Firefox has an experimental implementation, which lead to some good
> feedback. For example, we've had a bug report that suggests we should
> block importScript(), since there is no way to supply integrity metadata
> with importScript().
>
> This inadvertedly leads to follow-up questions:
> 1) What should require-sri-for do for other methods that do not allow
> fetch-options (e.g. @import and url() in CSS)?


> 2) What should require-sri-for do for same-origin resources (Workers,
> importScripts etc. can not load cross-origin)?


>
> My thoughts so far:
>
> re 1) I don't think there's anything we can do besides blocking, if we
> want require-sri-for to be a security feature that websites rely on.
>

In `require-sri-for` implementation in Chrome [1], the goal was to require
integrity
metadata for all possible mechanisms of loading scripts and styles,
including preloads and prefetches.

Most of those mechanisms do not provide a way to specify integrity metadata
today, and the hope is
that eventually those ways will be covered in the next iteration of SRI
spec. I would expect that when new
mechanism to load resources is invented, browsers will ship it with a way
to provide integrity metadata.


> re 2) I've been thinking about this myself and would consider allowing
> same-origin loads without integrity metadata. It just does not fit the
> use case of not having to trust a CDN.
>

I agree with others that same-origin resources should not be treated
differently from cross-origin
ones.
[1] https://www.chromestatus.com/feature/5635811978510336

>
>
>
> Looking forward to hearing your input!
> Freddy
>
>
>
> [1] I am thinking about changing the syntax, see other email.
> [2]
> https://github.com/w3c/webappsec-subresource-integrity/pull/
> 32#issuecomment
>
>