Possible trustedTypes bypass when assigning to script.innerHTML

[securityMB]

Not sure if this has been covered before, but my quick search didn't yield any results. The issue is that certain webpages might assign a string (purposely or by mistake) to scriptTag.innerHTML. In this case, createHTML is called, instead of createScript (even though, effectively, a script is created). This might lead to XSS-es since HTML sanitizers won't probably sanitize alert(1) in any way.

Here's an example:

<meta http-equiv=content-security-policy
      content="trusted-types default">


<script id=magic></script>
<script>
  // simulate a good sanitizer
  const sanitize = s => s;
  
  const tt = trustedTypes.createPolicy('default', {
    createHTML(s) {
      return sanitize(s);
    },
    createScript(s) {      
      return ''; // no eval at all!
    }
  });
  
  document.querySelector('#magic').innerHTML='alert(1)'; 
  
</script>

In the case above, alert(1) gets executed even though the policy explicitly forbids creating scripts from a string.

[koto]

Yeah, that would be covered by #236.

[koto]

@otherdaniel - Daniel, this seems like a good example to include in the WPT test for the slot approach.

[koto]

Confirmed that the bypass doesn't work in current Chrome 82 (Canary). The createHTML function is called on innerHTML assignment, but that value is then processed by createScript function when the script is about to execute (as outlined in https://w3c.github.io/webappsec-trusted-types/dist/spec/#prepare-script-url-and-text)