Re: E4H and constructing DOMs

> 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.

/ Jonas

Received on Monday, 11 March 2013 08:06:16 UTC