On Mon, 12 Jul 2021 at 19:57, Craig Francis <cr...@craigfrancis.co.uk> wrote:
> the “go-safe-html” library authors decided that > "the ergonomics of trusting concatenated constants far outweighs the security > concern". Go is a quite different programming language to PHP. When they say 'constants', they appear to be able to enforce that by using a clever feature of that language https://github.com/google/safehtml/blob/2057dd9c30f9e264f4d01c29d886d51f1b519302/template/template.go#L440-L452 : ``` // stringConstant is an unexported string type. Users of this package cannot // create values of this type except by passing an untyped string constant to // functions which expect a stringConstant. This type must be used only in // function and method parameters. type stringConstant string func stringConstantsToStrings(strs []stringConstant) []string { ret := make([]string, 0, len(strs)) for _, s := range strs { ret = append(ret, string(s)) } return ret } ``` i.e. this code works, as the url template is an actual string constant (not a variable): ``` safehtml.TrustedResourceURLFormatFromConstant( `//www.youtube.com/v/%{id}?hl=%{lang}`, map[string]string{ "id": "abc0def1", "lang": "en", }) ``` Attempting to use a string variable, fails to even compile: ``` format := `//www.youtube.com/v/%{id}?hl=%{lang}` safehtml.TrustedResourceURLFormatFromConstant( format, map[string]string{ "id": "abc0def1", "lang": "en", }) cannot use format (type string) as type safehtml.stringConstant in argument to safehtml.TrustedResourceURLFormatFromConstant ``` The current JavaScript equivalent ideas for string literals appear to be inactive or archived: * https://github.com/mikewest/tc39-proposal-literals - This repository has been archived by the owner. It is now read-only. * https://github.com/tc39/proposal-array-is-template-object - not particularly active. But my understanding is that like the Go implementation, they are proposing to enforce literal-ness of function parameters through special compilation rules for parameters to function calls, rather than passing literal strings around to arbitrary places - below* or https://tc39.es/proposal-array-is-template-object/#sec-gettemplateobject The other JavaScript approach for dealing with trusted types (https://auth0.com/blog/securing-spa-with-trusted-types/) is even more different than this proposal. It seems pretty inaccurate to claim that either the safehtml library or the proposal for JavaScript support the choice made for the PHP RFC. They don't appear to actually allow carrying literal-ness through variables, only through compile-time constants that are placed inside the parentheses or a function call. They also work in a different way, and use features of those languages not available in PHP. cheers Dan Ack * this is the definition for the proposed JavaScript literal implementation, I think. ``` Runtime Semantics: GetTemplateObject ( templateLiteral ) The abstract operation GetTemplateObject is called with a Parse Node, templateLiteral, as an argument. It performs the following steps: 1. Let realm be the current Realm Record. 2. Let templateRegistry be realm.[[TemplateMap]]. 3. For each element e of templateRegistry, do a. If e.[[Site]] is the same Parse Node as templateLiteral, then i. Return e.[[Array]]. 4. Let rawStrings be TemplateStrings of templateLiteral with argument true. 5. Let cookedStrings be TemplateStrings of templateLiteral with argument false. 6. Let count be the number of elements in the List cookedStrings. 7. Assert: count ≤ 232 - 1. 8. Let template be ! ArrayCreate(count). 9. Set template.[[TemplateObject]] to true. 10. Let rawObj be ! ArrayCreate(count). 11. Let index be 0. 12. ... ``` -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php