Consider dropping TrustedURL

[koto]

We started integrating the application with the polyfill. So far the biggest obstacle is the TrustedURL enforcement. It turns out linking to other content is common in the web (who knew?).

Guarding how application produces URLs is important for XSS prevention because of a presence of scriptable protocols like javascript: (same-origin) or data: (cross-origin). Historically, there were also other URL schemes like jar: that could result in an XSS.

It's also desirable for non-XSS related reasons. Some examples:

• navigating to custom URL handlers might initiate actions harmful to users (e.g. [tel:], (https://tools.ietf.org/html/rfc3966#section-11), facetime:, android intents, chrome-extension://)
• some applications may want to prevent directing their users to external sites
• defacement / spoofing risks when loading subresources from 3rd party sites
• IP address of the user may be disclosed, together with other fingerprintable data, when a http: resource is fetched from a https: document
• creating iframes from malicious URLs may enable exploitation of other bugs (e.g. when a postMessage channel is established without verifying peer origins).
• loading subresources from different origins into the same renderer process might data exfiltration via Spectre-like bugs.
• attacker-controlled stylesheets may exfiltrate data from the document
• pointing a form to external URL via action or formaction attributes may exfiltrate data (usually, credentials)
• <base> URL might be used to hijack all relative links.

However, in practice, for DOM XSS prevention alone it's enough if following the URL will not execute a script in a same-origin document. The check for this is simply - after parsing, and making the URL absolute, make sure it's not a javascript: one. In other words, there's no user-controlled sanitization required for a.href and other standard URL sinks. It's enough if the document behaves like it would under script-src *, without unsafe-inline keyword.

In that spirit, we might simply drop the TrustedURL type and mandate that, under TT enforcement the host environment disables javascript URLs (like if there was a script-src without unsafe-inline). Such behavior is polyfillable (e.g. URL may be used to correctly parse a URL and extract the protocol). This offers a very simple DOM XSS containment (only policies may introduce DOM XSS) setting:

Content-Security-Policy: trusted-types [policy-list]

Authors could still introduce additional restrictions to URLs via *-src directives or navigate-to to address risks other than DOM XSS via URLs.

[koto]

CSP trusted-types * will require TrustedURL type for URL sinks. CSP trusted-types * 'url-allow-http' will also transparently promote http: and https: URL strings into typed values. As such, websites can still have control over how URL sinks are being used, can even use javascript: URLs by wrapping them with types. At the same time sites can opt-in to skip the policies for URL sinks in a way that won't cause DOM XSS. data: and other protocol URLs would still need to be typed, and the change doesn't affect TrustedScriptURL sinks.

One more non-XSS reason for the websites to want to guard URL creation is HTTP authorization prompts from subresources, that could be used for phishing. See e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1357835 and https://bugs.chromium.org/p/chromium/issues/detail?id=239918