Re: E4H and constructing DOMs

On Mon, Mar 11, 2013 at 1:05 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Fri, Mar 8, 2013 at 5:53 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>> On Fri, Mar 8, 2013 at 1:15 PM, Adam Barth <w3c@adambarth.com> wrote:
>>>> 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 don't think it's that important to assign blame.  There's plenty of
>> evidence that developers are very happy with AST-based solutions when
>> done well.  For example, many, many developers use prepared statements
>> for SQL and Haml for HTML.
>
> Without knowing where the problem lies, it's hard to say that the
> proposed solutions are going to be effective.
>
>>> Indeed, since string templates don't even need to return strings, you could do
>>>
>>>     header.appendChild(htmlel`<h1>Welcome ${ firstName } ${ lastName }!</h1>`);
>>>
>>> where `htmlel` just returns an HTML element constructed using that same algorithm (instead of the `outerHTML` of that element).
>>>
>>> At this point it seems like you are bikeshedding over `@` vs. `htmlel` or `{}` vs. `${}`, which leads me to believe I must be missing your argument, especially since you emphasize you're not wedded to ES4H and thus presumably not wedded to `@` or `{}`.
>>
>> I don't care at all about the syntax.  If you want to keep backtick as
>> the operator, that's fine.  What's important to me are the following:
>>
>> 1) The template system parses the trusted template content separately
>> from the untrusted input data.  In particular, it should fill the
>> untrusted data into the leaves of AST produced by parsing the template
>> rather than parsing the untrusted data.
>>
>> 2) The template system does the above by default.
>>
>> Specifically, I would be perfectly happy with the following syntax:
>>
>> header.appendChild(`<h1>Welcome ${ firstName } ${ lastName }!</h1>`);
>>
>> as long as this "hello, world" template is not XSS.
>
> Note that quasis would fulfill that requirement as long as there is no
> default quasi. I.e. as long as:
>
> `foo ${ x }`
>
> is a syntax error but
>
> html`foo ${ x }`
>
> is not.
>
> But it's unclear to me if you'll be able to convince people that
> string templates are evil in enough contexts that they should be
> abandoned.

I see that I'm late to the party and that this proposal has already
been debated. I'm happy to see that it is receiving serious
consideration.

But yes, I was always assuming that the html`...` would return a DOM
tree. As long as the html quasi handler treats all inserted data as
not-parsed-as-markup by default (see my earlier examples for opting in
to more unsafe parsing), and as long as there exists no default quasi
handler, I think we should be in a pretty good state even compared to
E4H.

There is still the risk that people do "elem.innerHTML = string`...`"
where "string" is either a built-in quasi handler, or one that's
supplied by the author. But I'm not sure that the risk is that much
bigger than people doing "elem.innerHTML = '...' + x"

/ Jonas

Received on Monday, 11 March 2013 08:17:30 UTC