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