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

Re: html template string handler WAS: E4H and constructing DOMs

From: Adam Barth <w3c@adambarth.com>
Date: Mon, 11 Mar 2013 13:28:00 -0700
Message-ID: <CAJE5ia_T0bSC3ZhFkCHLdS7ECTdN1GzskCu2mMPOOr+ubm9C3g@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, Ian Hickson <ian@hixie.ch>, Ojan Vafai <ojan@chromium.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Mon, Mar 11, 2013 at 1:25 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Mon, Mar 11, 2013 at 1:12 PM, Adam Barth <w3c@adambarth.com> wrote:
>> On Mon, Mar 11, 2013 at 12:55 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
>>> On Mon, Mar 11, 2013 at 7:12 PM, Adam Barth <w3c@adambarth.com> wrote:
>>>> I'd recommend restricting untrusted data to text nodes.  That means we
>>>> wouldn't be able to support those sorts of templates becaue {foo}
>>>> would need to expand to something other than a text node.
>>> You mean not addressing the use cases related to attributes?
>> Yes.  (Note: E4H doesn't let template inputs expand to anything other
>> than a text node either.)
> Yes it does - E4H lets inputs expand into attribute values.  Anything
> which didn't allow *at least* this much would be unacceptable weak,
> and ignored by most authors.

Oh, attribute values are fine.  The example, which has been trimmed
from the context, was the input expanding to a sequence of attribute
name/value pairs.

> I believe that supporting attribute names, and perhaps tagnames, from
> inputs is also sufficiently useful and easy to secure.

Those seem pretty dangerous.  That lets the attacker choose things
like "onclick" and "script", which might lead to script execution.

Received on Monday, 11 March 2013 20:29:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:08 UTC