-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is "code updating a script before it finishes parsing" within the threat model of Trusted Types? #532
Comments
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 My understanding of the script-loading situation is that the 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. |
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. |
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. |
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?
The text was updated successfully, but these errors were encountered: