W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2016

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

From: Sergey Shekyan <shekyan@gmail.com>
Date: Mon, 12 Sep 2016 00:01:18 -0700
Message-ID: <CAPkvmc8K1zqzqTkf=kpFL385nbXrMG-9Z5wUKhwJbsxG2+s2HQ@mail.gmail.com>
To: Frederik Braun <fbraun@mozilla.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
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
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
[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
Received on Monday, 12 September 2016 07:02:09 UTC

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