Re: SRI fail open behaviour

On 18/07/15 07:14, Jonathan Kingston wrote:
> There is a discussion going off regarding the changes discussed at the
> Berlin F2F:
> https://github.com/w3c/webappsec/issues/317#issuecomment-120859303
> 
> This is regarding changing the behaviour of fail-open to fail-close
> whenever the following conditions are met:
> 
>   * we are loading a cross-origin resource
>   * the |integrity| attribute is non-empty (it could be valid or invalid)
>   * the |crossorigin| attribute is missing (i.e. it's not a CORS load)
> 
> If the request is a different origin without the correct CORS headers
> then the request still must fail open.

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.

I don't see any downsides from a compatibility point of view either.

> I'm also unsure if there is any benefit of failing open for unrecognised
> algos; it feels to me lack of control over older user agents would be a
> bad thing. A custom exception here would allow users to cater for those
> users I think.

The main downside I see to failing closed in that case is that we would
treat old SRI-enabled browsers worst than old non-SRI-enabled browsers.
For example, in the future if you have:

  <script integrity="sha3-Gk5l2Bi..." crossorigin="anonymous">

- 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.

> Perhaps a set of options that are not related to hash-expressions might
> be useful to fail close here or another attribute like:
> 'integrity-violations="throw-always"' (This could be a level 2 thing
> perhaps)

That would be an interesting thing to explore in V2 along with CSP
directives that would require that all subresources be protected with SRI.

Francois

Received on Saturday, 18 July 2015 12:48:05 UTC