Bypass via HTMLAnchorElement properties

[koto]

Found by @sirdarckcat:

It's still possible to execute the JS bypassing the policy by directly manipulating the HTMLAnchorElement properties like protocol, pathname etc.

a.href = TrustedTypes.createPolicy('foo', (p) => {
  p.createURL = (d) => d // actually sanitize here, but that's not relevant for the bypass.
}).createURL('http://notevil.com');

a.pathname='\nalert(1)';
a.protocol='javascript:';
a.click();

Full setup:

data:text/html,<meta http-equiv="Content-Security-Policy" value="trusted-types *"> <script src="https://wicg.github.io/trusted-types/dist/es6/trustedtypes.build.js"></script><a id=a>clickme</a><script>a.href = TrustedTypes.createPolicy(Math.random(), (p) => {p.createURL = (d) => d}).createURL('http://notevil.com');a.pathname='\nalert(1)';a.protocol='javascript:';a.click()</script>

Given that this can be abused by multiple properties, and each property requires only a part of the URL, it's not clear how the fix might look like, short of disabling the APIs, or just disallowing changing a.protocol (to javascript: or totally).

https://developer.mozilla.org/en-US/docs/Web/API/HTMLAnchorElement mentions that these properties are experimental.

[koto]

One countermeasure @jonathanKingston proposed is tracking which policy object was used to set the attribute we cover (e.g. <a href>) and calling it with the serialization of changed href when it would change (e.g. when a.protocol was changed). That would require tracking which policy was used when, and could be bypassed e.g. when only the "partial" attributes (protocol, path, query etc.) are used, without any href assignment.

Another option would be to always call a default policy (and reject if it doesn't exist) on those partial attribute setters. That doesn't require tracking and can allow for setting some baseline rules for corner cases like that.

Another option would be to outright disable setting some of the attribute setters - it's easy to prevent JS execution that way, but it doesn't map well to TT effort of being able to control URL creation in your application in general.

cc @otherdaniel - are any of these feasible to implement?

[empijei]

could be bypassed e.g. when only the "partial" attributes (protocol, path, query etc.) are used, without any href assignment

What about rebuilding the full URL and treating all changes as href assignments?
For example invoking a.protocol = 'javascript:' re-applies the policy with 'javascript://notevil.com'.
If the policy sanitizes javascript URIs it will prevent injection.

[koto]

That approach assumes that a policy was previously invoked. I assumed that:

a = document.createElement('a');
a.protocol = 'javascript:'
// other "partial" attribute changes

would be a bypass for that (as href setter was never called with a TT). However, I now notice that href is not actually changed for those, so maybe it's ok :)

[koto]

Spec-wise it sounds like hooking into https://html.spec.whatwg.org/multipage/links.html#concept-hyperlink-url-set would address this bypass, it's just not clear yet whether we want to call a default policy or the original one.

[mikesamuel]

Are we confident that putting guards at primitives addresses this issue?

If not, should I disable .protocol assignment based on stringAtSinkDisposition for v1. We could always open it up partially later on.

[koto]

We might be able to sidestep the issue by blindly disabling javascript: URLs if TT are enforced.