Skip to content
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

Add fromLiteral #411

Open
mbrodesser-Igalia opened this issue Jan 23, 2024 · 5 comments
Open

Add fromLiteral #411

mbrodesser-Igalia opened this issue Jan 23, 2024 · 5 comments
Milestone

Comments

@mbrodesser-Igalia
Copy link
Collaborator

See #398.

@mbrodesser-Igalia mbrodesser-Igalia added this to the v2 milestone Jan 23, 2024
@lukewarlow
Copy link
Member

Just to note a thought I had, if / when we spec fromLiteral again, I think we should make it opt-in rather than it always being allowed. I propose a new keyword for the trusted-types directive of 'literal' (can bikeshed this if we don't like it). And only when you include 'literal' in your list of trusted-type policies in CSP is it allowed.

This way require-trusted-types-for 'script'; trusted-types 'none'; truly does disable the legacy sinks.

Obviously fromLiteral would also work if you didn't include trusted-types as a directive in your CSP, the same way createPolicy does.

@koto
Copy link
Member

koto commented Apr 3, 2024

We discussed this in the past, and concluded that fromLiteral should be always allowed. There's no interpolation, and template literals can only be created from syntax, so no dynamic user-controlled value can reach fromLiteral tags (at least not in the DOM XSS sense - it's possible to create dynamic template strings server side, or from eval, but this would be outside of TT threat model).

@lukewarlow
Copy link
Member

If we imagine a future with the sanitizer API, I personally think it's valuable to have a way to completely disable the legacy sinks. I know it's not directly part of the threat model of TT but still feels like it could be useful, and doesn't have much of a down side?

Just something I think is worth considering again when the time comes.

@annevk
Copy link
Member

annevk commented Apr 3, 2024

What do you mean by a legacy sink? A place that accepts Trusted*? Cause we're also adding new entry points of that kind.

But also, if you want certain APIs to not work, changing them directly is probably a better way instead of action-at-a-distance that might not hold over time unless we're very careful. I.e., we could just have a boolean that makes anything that takes Trusted* throw.

@lukewarlow
Copy link
Member

lukewarlow commented Apr 3, 2024

What do you mean by a legacy sink?

Sorry yeah to clarify by legacy sink I mean something like innerHTML as opposed to setHTML.

Cause we're also adding new entry points of that kind.

That's a good point, setHTMLUnsafe is an interesting one because it's not safe but does support the sanitiser and is clearly a "modern" API and perhaps that's a good reason why we can't just (advocate to) permanently disable all sinks that take a Trusted type using the CSP as I was suggesting above.

But also, if you want certain APIs to not work, changing them directly is probably a better way instead of action-at-a-distance that might not hold over time unless we're very careful. I.e., we could just have a boolean that makes anything that takes Trusted* throw.

Yeah you're probably right, something like this fromLiteral case is already an example of an API change that changes the assertion that the TT CSP can guaruntee these sinks are disabled. So perhaps that is best left to something else.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants