"Whitelisting external JavaScript with hashes" incorrectly assumes encoding of sources

[joelweinberger]

In Whitelisting external JavaScript with hashs, the spec mentions that if there is integrity metadata on an element, it must match the hash-sources. However, SRI and CSP subtly use different resource bodies to compute digests. SRI computes digests on the raw resources (i.e. applying the digest algorithm to the representation data) while CSP applies digests to an encoded string (as discussed in #109, in practice UAs apply it to the UTF-8 encoding while the specs actually apply it to the UTF-16 encoding).

I'm not sure of the best solution to this since, inherently the integrity metadata is potentially different from the hash source list. We could special case UTF-8/16 encoded resources, but that seems odd. Offhand, it seems like this section isn't possible with how the digests are currently computed.

[mikewest]

/cc @fmarier

[andypaicu]

Disclaimer: this bug is very old so it's possible that when it was raised the specs were substantially different than they are currently and perhaps it has already been addressed but without being linked to or closed.

I believe this might not be as bad as it initially seems because the CSP computed hashes and the SRI computed hashes are never actually used to compare against each other.

What I mean is the CSP spec will only check if a valid integrity attribute with matching hashes exists. It then hands off the actual enforcement to the SRI spec (see https://w3c.github.io/webappsec-csp/#script-pre-request). This is done for script-like requests.

The situations where a hash is computed by CSP is for inline checks where the body of the resource being checked is readily available in the element, and in that case the integrity attribute is not involved at all (see https://w3c.github.io/webappsec-csp/#match-element-to-source-list which is called from script/style inline checks).

This discrepancy will basically mean that an inline script and an external script that have the same text will potentially (likely?) have different hash values because of the difference between the way CSP and SRI compute hashes. I don't personally think that's too bad, perhaps writing a note explaining why this happens is enough.

@metromoxie, @mikewest What are your thoughts on this?

[annevk]

That sounds about right to me. And since non-UTF-8 is invalid (per the Encoding Standard), it shouldn't be a problem in practice either for those producing conforming code.