Re: E4H and constructing DOMs

2013/3/11 Bjoern Hoehrmann <derhoermi@gmx.net>:
> * Mike Samuel wrote:
>>Ok.  So it's not a goal of E4H to be safe against XSS by default then.
>
> I think we are all agreed that any template mechanism should be robust
> against code injections in some manner, particularily including that any
> such mechanism should not allow expanded parameters to escape boundaries
> that authors assume when looking at the template code, so when you have
>
>   <example example='${...}'>...
>
> authors would assume that whatever `${...}` expands to stays within the
> `example` attribute value and any template mechanism should not violate
> that assumption. If there is a consensus about that, then I find claims
> such as yours above, and discussions about "string-based" versus "AST-
> based" solutions rather distracting.

I agree that string-based vs AST-based is not a core issue and
apologize for distracting you.
On the larger issue, I don't think we have consensus on the definition
of "safe."  Boundaries (the structure-preservation property) are only
part of the problem.

E4H does a fine job of ensuring in

   <><a href="{x}">...</a></>

that the tag ends where the template author expects it to, and that
there are no unexpected attributes.

It does not however prevent an attacker who controls (x) from causing
arbitrary javascript to run when the link is clicked.

I don't think it is appropriate to call it safe against XSS .  I think
a better term for the E4H guarantee is that it is safe against
element/attribute injection.  I don't think that safety guarantee is
worth the effort of specing E4H or including it in browsers.

Received on Tuesday, 12 March 2013 02:26:42 UTC