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

Re: SRI fail open behaviour

From: Brad Hill <hillbrad@gmail.com>
Date: Wed, 05 Aug 2015 17:19:35 +0000
Message-ID: <CAEeYn8gc0UaZ91Jq-41NKYbz3F-1J+SwNO4e9_wrfq7sJsMb=A@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>, Francois Marier <francois@mozilla.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
This goes back to some of the early design suggestions where we had things
like src="safe_url" alt-src="CDN_url" alt-src-integrity="...".  We decided
to cut those features for Level 1.  I'm not sure how requiring at least one
valid hash recognized by an SRI-aware browser helps with the case where a
website wants to send a different link for browsers that don't do SRI at
all, or which don't recognize the algorithms chosen.

On Wed, Aug 5, 2015 at 9:48 AM Brian Smith <brian@briansmith.org> wrote:

> Francois Marier <francois@mozilla.com> wrote:
>> If we wanted to enforce integrity protection, we would have done
>> something like:
>> <script integritysrc="safe.js" integrity="sha256-....">
>> which would mean that only a browser with SRI support will load the
>> script.
> I think that's only considering the case where SRI is "nice to have" vs
> the case where SRI is critical. For older browsers, you just can't safely
> send <script src=https://untrusted-cdn.example.com/foo.js>. My goal is to
> make it as safe as possible to send <script src=
> https://untrusted-cdn.example.com/foo.js integrity=sha256-ABC...> when
> you know the browser supports SRI when the distinction really significantly
> matters.
>> We didn't do that however, we made integrity a "bonus" for SRI-enabled
>> browsers while still loading the script in older browsers.
> That's only one use case for SRI, and it's the least interesting one. The
> more interesting case is where the website feels it has to send a
> completely different link to non-SRI-supporting browsers.
>> > Consequently, I still think the best thing to do is to just make SRI
>> > fail closed if there is any problem (parsing or otherwise) with
>> > enforcing SRI.
>> If we block loads on parsing errors, then we are essentially locking
>> ourselves into a specific syntax for the attribute, which would limit
>> what future versions of this spec can do.
>> I agree there are UX benefits to failing closed, but there is a cost in
>> terms of future extensibility as well.
> That's easy to deal with. The SRI attribute is already defined to have a
> syntax of space-separated expressions. My suggestion is to require at least
> one of those expressions to be a syntactically-valid hash-with-options that
> identifies a digest that has been verified to match the content. If there
> is other stuff (junk or other unsupported algorithms), then that's not an
> issue, as long as there's one valid hash-with-options.
> Cheers,
> Brian
> --
> https://briansmith.org/
Received on Wednesday, 5 August 2015 17:20:13 UTC

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