Re: E4H and constructing DOMs

On Mar 8, 2013, at 6:04 PM, Domenic Denicola wrote:

> From: Adam Barth [mailto:w3c@adambarth.com] 
> 
>> Right, that's why the example in my first email is XSS:
> 
>>    var firstName = [...];
>>    var lastName = [...];
>>    header.innerHTML = `<h1>Welcome ${ firstName } ${ lastName }!</h1>`;
> 
>> Whereas the E4H equivalent would not be:
> 
>>    var firstName = [...];
>>    var lastName = [...];
>>    header.appendChild(@<h1>Welcome { firstName } { lastName }!</h1>);
> 
> 
> I must be missing something, but from my reading you are not gaining anything in the ES4H example over the string templates example, if of course you modify the last line to be
> 
>    header.innerHTML = html`<h1>Welcome ${ firstName } ${ lastName }!</h1>`;
> 
> In particular, as has been explained in this thread a few times, there's no reason why browsers can't ship a built-in `html` template handler that does the same AST-based DOM parsing on the passed template string that ES4H would do on the source string following the @-sign, and subsequently returns the `outerHTML` of the resulting DOM element. Indeed, since string templates don't even need to return strings, you could do
> 
>    header.appendChild(htmlel`<h1>Welcome ${ firstName } ${ lastName }!</h1>`);

or even

      header.appendTemplatedChild`<h1>Welcome ${ firstName } ${ lastName }!</h1>`;

Such a tag function ould impose whatever semantic validation is appropriate to both the template and the validation and never directly expose the intermediate subtree to the client code. Heck, it can even perform contextual validation based upon the actual parent node.

The fundamental issue here seems to be an API design issue, not a language design issue.  Template strings and their tags are general purpose language constructs that have many uses besides supporting dynamic DOM construction. The real hazard is the existence of innerHTML. 

Template strings and tags is another capability you can factor into designing web APIs and hopefully will result in better, more reliable APIs.  But ECMAScript is a general purpose language and its string processing features must support many use cases.  ES string processing would have no general utility if it was sufficiently neutered to a degree that XSS attacks using innerHTML were impossible. that's not going to happen.

Allen

Received on Saturday, 9 March 2013 23:05:54 UTC