Ensure brands are tied to their evaluation
bakkot opened this issue · 5 comments
Whatever implementation is used for this, I think the following invariant is important:
If some code has access to a code-like object x which is coerced the string y when passed to eval, but does not have access to a mechanism for creating other code-like objects, then it should not be possible for this code to create an object which coerces to any string other than y when passed to eval.
For example, it should not be possible to just override the toString of x, assuming that is what is used for coercion. Similarly it should not be possible to copy the brand from x to a different object with a different toString, or to wrap x in a Proxy which overrides the get handler to return a different value for toString.
If this invariant does not hold, you need to audit any code downstream of the thing which can create code-like objects, not just that code itself. That's a much trickier problem.
I believe this is the case. If there're no webcompat tests that try to set toString on a trusted value, I'll add them.
I'll add a note for implementors to this effect too.
@bakkot your concern is about the host callout implementation, right? For Trusted Types in specific we have that as the only code-like objects would be TrustedScripts and the string coercion for eval done in HostBeforeCompileValue takes a value from the slot, and does not call the stringifier function.
Would the proper resolution be to add a note about the invariant in https://tc39.es/proposal-dynamic-code-brand-checks/#sec-hostbeforecompilevalue ?
@bakkot, would the proper resolution be to add a note about the invariant in https://tc39.es/proposal-dynamic-code-brand-checks/#sec-hostbeforecompilevalue ?
@koto My main concern is about the actual mechanism of Trusted Types, not about the ECMA-262 spec text. Such a note would probably be a good idea for future implementors (though I'm not sure how to word it), but as long as the actual HTML-side implementation of the host hook preserves this invariant (and browsers do as well), I'm satisfied.
(Apologies for missing your previous comment.)
@bakkot Please see the updated text - now the IsCodeLike check relies on the presence of the host-defined internal slot for the object, and the stringification happens on ES's side. I added the note about the invariant.