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

Re: SRI fail open behaviour

From: Francois Marier <francois@mozilla.com>
Date: Sun, 19 Jul 2015 17:17:03 -0400
Message-ID: <55AC13CF.2020009@mozilla.com>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
On 18/07/15 09:05, Jonathan Kingston wrote:
>     I think failing closed (blocking the load) is the right thing to do in
>     this case since it's too easy for a developer new to SRI to forget the
>     crossorigin attribute and think that the integrity is checked by the
>     browser. We of course have console warnings, but a hard fail is harder
>     to miss.
> So if I specify the 'crossorigin' attribute but the server doesn't send
> the correct headers, I thought the only safe thing here was to fail open
> with no exceptions?

If you specify a crossorigin attribute and the resource is not
CORS-enabled on the server then the load will fail in the networking
layer (before it hits SRI).

>     - Chrome 80 will load this just fine because it implements "sha3"
>     - IE 9 will load it too because it doesn't have support for SRI at all
>     - Firefox 42 would block it because it supports SRI but not sha3
>     Of course, developers can specify more than one hash algorithm (and they
>     should in this case), but the point is that if you encounter the above
>     integrity attribute in the wild, then an old SRI-enabled browser is more
>     broken than a really old browser.
> Yup but at that point we would likely want to block IE9 through poor
> crypto cyphers anyway. From a security perspective having support to
> block Firefox 42 in your example would be useful and yes I likely would
> have a fallback to support them in reality.

If we wanted to block old browsers without support for SRI, we'd have to
do something like use an alternative "src" to ensure that
non-SRI-enabled browsers from having a script source at all.

Received on Sunday, 19 July 2015 21:17:34 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:13 UTC