navigation requests blocked by require-trusted-types-for don't set a violation sample

[fred-wang]

From 4.2.4. Should navigation request of type be blocked by Content Security Policy?, step 2.1.1 will execute the 4.3.1.1. require-trusted-types-for Pre-Navigation check. Step 4 is as follows:

Let convertedScriptSource be the result of executing Process value with a default policy algorithm, with the following arguments:

• TrustedScript as expectedType
• request’s clients's global object as global
• encodedScriptSource as input
• "Location href" as sink
• If that algorithm threw an error or convertedScriptSource is not a TrustedScript object, return "Blocked" and abort further steps.

When "Blocked" is returned to 4.2.4. Should navigation request of type be blocked by Content Security Policy?, the algo continues by creating a violation object and reporting it.

I don't see any place where violation's sample is actually set, but trusted-types/trusted-types-navigation.html expects it to starts with the sink name "Location href" similar to 4.3.4. Should sink type mismatch violation be blocked by Content Security Policy? and that's what Chromium seems to implement.

cc @koto @otherdaniel @lukewarlow @smaug----

[lukewarlow]

Yeah you're right this seems to come from the disconnect between Trusted Types and CSP.

Not sure on the best way to spec this tbh.

Potentially we should allow it to return two values and update the csp spec to have an optional second sample value?

[fred-wang]

cc @otherdaniel @koto

I'm trying to write more WPT tests at https://bugzilla.mozilla.org/show_bug.cgi?id=1958311 for pre-navigation check, as current set is limited. This is still WIP but I noticed a couple of things in Chromium, which might be due to the disconnect you mentioned:

• Chromium does not report a violation if the default policy throws. This is consistent with https://w3c.github.io/trusted-types/dist/spec/#get-trusted-type-compliant-string-algorithm (which does not report violations in that case) but not with https://w3c.github.io/trusted-types/dist/spec/#require-trusted-types-for-pre-navigation-check which says "Blocked" should be reported if the algorithm throws, and so https://w3c.github.io/webappsec-csp/#should-block-navigation-request would report a violation.

• Chromium sometimes seems to do double reporting of violations for report-only directives (see "One report-only require-trusted-types-for 'script' directive" from testing/web-platform/tests/trusted-types/navigate-to-javascript-url-004.html for example). I wonder if this is because there are two violation reporting paths (one for TT and a generic one for CSP)?...

I haven't tried on Safari yet.

Incidentally, I'm not quite sure when the reparsing of the "javascript:" url can fail (step 6 of https://w3c.github.io/trusted-types/dist/spec/#require-trusted-types-for-pre-navigation-check). It seems in Firefox, that can be for ill-defined UTF-16 string but I was not able to write a test for that. edit: Also added tests for invalid url based on @annevk 's suggestion.

[annevk]

If you can make convertedScriptSource a value such as //test:test/ then the URL parser should fail on it: https://jsdom.github.io/whatwg-url/#url=amF2YXNjcmlwdDovL3Rlc3Q6dGVzdC8=&base=YWJvdXQ6Ymxhbms=