Re: E4H and constructing DOMs

On Fri, Mar 8, 2013 at 1:15 PM, Adam Barth <w3c@adambarth.com> wrote:
> On Fri, Mar 8, 2013 at 12:48 PM, Allen Wirfs-Brock <allen@wirfs-brock.com>
> wrote:
>>
>> On Mar 8, 2013, at 12:13 PM, Jonas Sicking wrote:
>>
>> On Fri, Mar 8, 2013 at 9:57 AM, Adam Barth <w3c@adambarth.com> wrote:
>>
>> Even if we had a secure HTML quasi handler, the HTML quasi handler
>>
>> would not be the default handler.  That means the templating system is
>>
>> insecure by default.
>>
>>
>> I'm not sure what you mean by "the default one". As I understand it
>> there's no such thing as a default quasi handler. You always have to
>> explicitly choose one.
>>
>>
>> There is no "default handler" but if a template string is not prefixed by
>> a handler tag then its semantics is to simply do string interpolation
>> without observably calling a hander or applying any semantic processing.
>
>
> Right, that's why the example in my first email is XSS:
>
> ---8<---
> var firstName = [...];
> var lastName = [...];
> header.innerHTML = `<h1>Welcome ${ firstName } ${ lastName }!</h1>`;
> --->8---

It's hard to say if the blame for this is with quasis or with
.innerHTML though. I.e. would not having quasis cause people to use
your AST based template system, or would they just use string
concatenation?

I agree that AST solutions have advantages. But the cost of
introducing them is really high and as far as I can tell there is no
way to create a generic AST-based solution. I.e. if we wanted to do
something SQL-like for querying databases we'd have to invent a whole
new JS syntax for that too.

/ Jonas

Received on Saturday, 9 March 2013 01:54:31 UTC