Re: E4H and constructing DOMs

On Fri, Mar 8, 2013 at 9:57 AM, Adam Barth <w3c@adambarth.com> wrote:
> On Thu, Mar 7, 2013 at 9:59 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> I thought that one of the points with quasis was that they would allow the
>> above to be interpreted such that firstName and lastName was inserted as
>> text content. I.e. the quasi handler could avoid parsing the contents of
>> those values as HTML and instead just inset them as text content.
>
> In my example, I used string templates (aka quasis) in their default
> mode, which is insecure, hence my claim that string templates are
> insecure by default.  Mike Samuel claims that he has written a
> safeHTML quasis handler, which takes about a thousand lines of
> JavaScript, hence my claim that string templates are difficult to use
> securely.

I'm not saying that we should rely on JavaScript to create a safeHTML
quasi handler. I'm saying that the platform should provide one.

>> This would mean that the HTML quasi would by default be resilient against
>> HTML-injection.
>
> 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.

>> To supplement this behavior we could allow the quasi to take special values
>> which would be passed to the HTML parser "like normal" and thus be parsed.
>> I.e. something like
>>
>> HTML`<h1>Welcome ${ asUnsafeHTML(firstName) } ${ lastName }!</h1>`
>>
>> In this case the asUnsafeHTML function would return an object which was
>> recognized by the HTML quasi as "should be parsed" and would contain a
>> property which holds the string value passed in the first argument.
>>
>> Since no parsing would take effect at the asUnsafeHTML callsite, and instead
>> would happen while the rest of the quasi was parsed, all of the normal
>> contextual parsing rules would apply.
>>
>> This way the quasi should by default be as safe as an AST template system,
>> while allowing the page to opt in to more feature full, less safe
>> templating.
>>
>> We could even provide functions like asSafeHTML which would trigger the
>> quasi to parse that piece of content using rules that prevent only "safe"
>> elements.
>
> None of the above solves the problem that string templates as
> currently designed are insecure by default and will lead authors to
> write code filled with XSS vulnerabilities.

It seems like your argument is that providing a AST-based templating
system is going to be more effective at migrating people off of string
concatenation together with .innerHTML, than providing a built-in
quasi handler which is safe-by-default would be.

Is that accurate? If so, what's the basis for that argument?

/ Jonas

Received on Friday, 8 March 2013 20:14:50 UTC