- From: Adam Barth <w3c@adambarth.com>
- Date: Sat, 9 Mar 2013 15:13:26 -0800
- To: Allen Wirfs-Brock <allen@wirfs-brock.com>
- Cc: Domenic Denicola <domenic@domenicdenicola.com>, Jonas Sicking <jonas@sicking.cc>, Anne van Kesteren <annevk@annevk.nl>, Rick Waldron <waldron.rick@gmail.com>, Adam Klein <adamk@chromium.org>, Ojan Vafai <ojan@chromium.org>, Brendan Eich <brendan@secure.meer.net>, Ian Hickson <ian@hixie.ch>, "rafaelw@chromium.org" <rafaelw@chromium.org>, Alex Russell <slightlyoff@chromium.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, "Mark S. Miller" <erights@google.com>
On Sat, Mar 9, 2013 at 3:05 PM, Allen Wirfs-Brock <allen@wirfs-brock.com> wrote:
> 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.
That's all fine and good, but it's non-responsible to my point, which
I will repeat again:
String templates as currently designed are insecure by default and will lead
authors to write code filled with XSS vulnerabilities.
You may not be willing to take these security considerations into
account when designing ECMAScript, but you can rest assured that
browser implementors will take them into account when decided whether
to implement string templates.
Adam
Received on Saturday, 9 March 2013 23:14:26 UTC