Is "code updating a script before it finishes parsing" within the threat model of Trusted Types?

[lukewarlow]

Based on lots of the discussions around the exact mechanics of TT enforcement within scripts, a question came up. Is code that ends up updating the contents of a script before it finishes parsing within the threat model of the Trusted Types API?

My understanding of the threat model is that it's based on trusted code manipulating untrusted strings into various XSS sinks.

That case doesn't seem to apply to this situation? It's reliant on at what would seem to be weird at best, or actively malcious at worst code?

cc @otherdaniel @koto @annevk and @mbrodesser-Igalia what are your thoughts on this?

[otherdaniel]

My understanding of the threat model is, (dynamically) constructed strings that get executed as javascript. Strings that are already on the loaded page -- such as <script> -- are not dynamically constructed by the page and thus shouldn't be TT-checked.

My understanding of the script-loading situation is that the <script> is surely on the page; if you try hard enough, you can stick in additional content into a <script> during page load; and this additional content would be executed. So the script that was executed was indeed dynamically constructed and quite different from the one on the original page. That seems to solidly cross the border that TT was meant to guard.

I think the only thing that makes this situation special is that it's difficult to exploit due to the required timing. But I don't think that creates a satisfactory security boundary.

[lukewarlow]

if you try hard enough.

The "you" here is the site author who we assume is trustworthy enough to not deliberately evade TT protections? Having to try hard to cause this to happen sounds like it would fall into "malicious author" to me?

[otherdaniel]

if you try hard enough.

The "you" here is the site author who we assume is trustworthy enough to not deliberately evade TT protections? Having to try hard to cause this to happen sounds like it would fall into "malicious author" to me?

I'm not sure this would require a "malicious author". It probably does require that user-controlled data is processed during page build-up, and it requires a slow script load. Both are imaginable in real-world applications.

The condition was originally found by a fuzzer. (https://g-issues.chromium.org/issues/40111196) IMHO the presence of a fuzz-exploitable loophole points more towards, could happen to an inattentive developer, rather than malicious.

[lukewarlow]

Okay thanks for answering! Looks like the answer is yes it is, so we do need to find a way to protect it that works in all browsers and can be specced.