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

Re: SRI fail open behaviour

From: Francois Marier <francois@mozilla.com>
Date: Tue, 04 Aug 2015 19:38:22 -0700
Message-ID: <55C1771E.4010203@mozilla.com>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
On 04/08/15 04:36 PM, Brad Hill wrote:
> We have two implementations shipping or nearly so, and I don't see any
> indication that any implementers are interested in making further
> changes beyond failing closed if CORS mode is not specified.  That being
> the case, any spec changes would have to be marked as AT RISK and likely
> backed out in a few months anyway in order to advance the spec.

It sounds like we have a rough consensus around failing closed on
missing CORS.

I'd like to propose the following test cases to clarify the mechanism:

(a) <script src=... integrity=""> : load
(b) <script src=... integrity="   "> : load
(c) <script src=... integrity="sha256-uxv92iM..."> : block
(d) <script src=... integrity="sha3-AKe8bj..."> : block
(e) <script src=... integrity="unknowntoken"> : block

All of these are missing CORS.

(a) and (b) are equivalent to not using SRI (i.e. <script src=...>) and
so they should load like normal script elements.

(c) is a well-formed integrity attribute but it's missing CORS, so we
should help the developer by failing hard.

(d) and (e) are not as obvious but my reasoning for blocking them is
that the developer has expressed a desire to use SRI but has forgotten
the mandatory crossorigin attribute. We should treat it like (c) so that
the CORS requirement is consistent with future browsers which may
recognize "unknowntoken" as a valid integrity attribute or support the
"sha3-" algorithm.

Received on Wednesday, 5 August 2015 02:38:53 UTC

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