Implicitly escaped $ (or not) in quasis?

Brendan Eich brendan at mozilla.org
Wed Jun 27 02:06:08 PDT 2012


gaz Heyes wrote:
> On 26 June 2012 17:19, Allen Wirfs-Brock <allen at wirfs-brock.com 
> <mailto:allen at wirfs-brock.com>> wrote:
>
>     I'm working on incorporating quasis into the ES6 draft and there
>     is an issue I want to discuss:
>
>     In the wiki proposal[1]  $  is used as the prefix for
>     substitutions that may be of two forms:
>        `xyz$foo 1234`      //$foo substitues the value of the variable foo
>        `xyz${foo} 1234`    ${expr} generally substitues the result of
>     evaluating expr, so ${foo} substitutes the value of foo
>
>
> I have to say I disagree with the whole feature, this will introduce a 
> new class of DOM based XSS attacks since developers in their infinite 
> wisdom will use this feature to place user input inside multi-line 
> strings. e.g. message = `USER_INPUT` and the attack being 
> ${globalVariable}.

This isn't much harder today with the fine + operator.

What quasiliterals enable is

   safehtml`... ${no_fear_here} ...`

instead of

   safehtml_but_slow("... ${no_fear_here} ...")

which has to parse out the ${} bits at runtime.

Any way you program, whether + or an API built on it or ES6 quasis, 
users have to remember to sanitize.

> A list of variable substitutions would mitigate that risk like how the 
> printf function works but allowing any variable reference is a bad 
> idea IMO.

What's the difference between

   `lit1 ${exp1} lit2 ${exp2} lit3`

and

   sprintf("lit1 %s lit2 %s lit3", exp1, exp2)

? Again, other than failing to have compile-time help checking that 
number of format specifiers matches number of trailing arguments 
(eliminated in quasis by embedding expN)?

> I would also like to see how the context aware escaping would work 
> since in order to provide such a mechanism you would have to render 
> the content at some point and the context could change and the user 
> input could change when the content is rendered. The fact that CSS 
> doesn't provide any way to safely escape user input in property 
> names/values without fully white listing the whole specification I 
> fail to see how a context aware escaping would work in that instance.

http://code.google.com/p/js-quasis-libraries-and-repl/source/browse/trunk/js/safehtml.js?r=137

/be


More information about the es-discuss mailing list