Conflicting SRI test cases for integrity checks and cross-origin hosts.

[TimvdLippe]

We are implementing the post-request check in Servo: servo/servo#37154 Based on our investigation, no other browser currently implements this check: servo/servo#37154 (comment)

After implementation, we ran into test failures in tests/wpt/tests/content-security-policy/default-src/default-src-sri_hash.sub.html. This test appears to verify the various integrity checks. We realized that the domain was wrong, where the test was using {{domain[www]}}, where the actual current domain is {{domain[]}}. That fixed a bunch of test cases for us.

However, now there are still test failures related to integrity matching. I see that this most recently was changed in #654. If I follow the logic for the following test case:

[ 'no integrity',
  './simpleSourcedScript.js',
  '',
  false ],

When we run https://www.w3.org/TR/CSP/#script-post-request on this:

1.2. We don't have a nonce, so continuing
1.3. We don't match integrity (since it is empty/not set)
1.4. We don't have strict-dynamic included
1.5. This response is allowed, since it is a same-origin request (it matches the host)

Hence we run into step 2, where we return allowed.

When I read the test, the intention (and the current browser behavior) is to reject this request. Relevant implementations:

• Chromium
• Gecko
• (Can't find WebKit as they don't use comments to refer to specs)

Based on the intention, I thought that #654 was the wrong way around, e.g. it should have been this:

If the result of executing § 6.7.2.4 Does integrity metadata match source list? on request’s integrity metadata and this directive’s value is "Does Not Match", return "Blocked".

That works for this particular test, but then we get to the actual post-request check failing a different test case:

[ 'crossorigin no integrity but allowed host',
  crossorigin_base + '/content-security-policy/script-src/crossoriginScript.js',
  '',
  true ],

E.g. this test now does the exact opposite: if the host matches, regardless of the integrity it should load it.

Given that no other browser implements this check yet, I am not sure what the correct behavior should be. I think updating the integrity check to "Does Not Match" is correct, but then what should we do with the crossorigin test case?

[TimvdLippe]

Tentative WPT PR with the test updates: web-platform-tests/wpt#52850

[TimvdLippe]

I just realised that the test and algorithm is probably correct after all. While investigating I saw that the Rust CSP crate was missing a check. This weekend I can debug more and confirm whether my current understanding is correct. If so, I will add comments to the test to make it more descriptive of what's going on.

[TimvdLippe]

My realisation is correct. The test is correct and the specification as well. The reason I got things mixed up, is that the CSP crate was missing the integrity check and then the test started failing in confusing ways. I have added clarifying comments to the test, to make a future reader aware of the nuances of the {{domain[www]}}.