search

tc39 / proposal-dynamic-code-brand-checks

TC39 proposal that enables flexible brand checks before dynamic code loading
MIT License
34 stars 5 forks source link

Ensure brands are tied to their evaluation #5

Closed bakkot closed 4 years ago

bakkot commented 5 years ago

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.

mikesamuel commented 5 years ago

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.

koto commented 4 years ago

@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 ?

koto commented 4 years ago

@bakkot, would the proper resolution be to add a note about the invariant in https://tc39.es/proposal-dynamic-code-brand-checks/#sec-hostbeforecompilevalue ?

bakkot commented 4 years ago

@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.)

koto commented 4 years ago

@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.