W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2013

Re: E4H and constructing DOMs

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 7 Mar 2013 21:59:31 -0800
Message-ID: <CA+c2ei8YdS76m0MtR7TBP8dNhcy=W9Jo-c=G4g6-X9XfwxBKvw@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
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>
On Mar 7, 2013 1:00 PM, "Adam Barth" <w3c@adambarth.com> wrote:
>
> On Thu, Mar 7, 2013 at 11:23 AM, Brendan Eich <brendan@secure.meer.net>
wrote:
> > I'd like to hear more about the security concerns with template
strings. I
> > couldn't find that at a glance among the three links Ojan footnoted.
>
> The general problem with template strings is that they're an XSS risk.
>  Essentially, we're encouraging authors to mix untrusted data into
> strings that will later be parsed by the HTML parser.  If the attacker
> is clever in selecting these untrusted strings, he'll be able to cause
> the remainder of the string to be parsed differently than the author
> intends.
>
> var firstName = [...];
> var lastName = [...];
> header.innerHTML = `<h1>Welcome ${ firstName } ${ lastName }!</h1>`;
>
> If firstName and lastName are are user-controlled (i.e., untrusted),
> the above is an XSS vulnerability.  For example, the attacker can set
> firstName to "<img onerror='alert(/pwned/)'>".

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.

This would mean that the HTML quasi would by default be resilient against
HTML-injection.

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.

/ Jonas
Received on Friday, 8 March 2013 06:00:01 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:09 UTC