- From: Adam Barth <w3c@adambarth.com>
- Date: Mon, 11 Mar 2013 13:28:00 -0700
- 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.
Adam
Received on Monday, 11 March 2013 20:29:01 UTC