Re: E4H and constructing DOMs

On Tue, Mar 12, 2013 at 5:07 PM, Mike Samuel <mikesamuel@gmail.com> wrote:
> 2013/3/12 Ian Hickson <ian@hixie.ch>:
>> On Tue, 12 Mar 2013, Mike Samuel wrote:
>>> I am merely proposing string templates which enable, among other things,
>>> easy integration of contextually auto-escaped applications.
>>
>> Not compile-time checked ones, right?
>
> No.  EcmaScript isn't compiled, so I don't know where compile-time
> checks would go.

ES is, in fact, compiled in every major engine.  But the more correct
term is "parse-time" anyway, I suppose - an early error that occurs as
the code is being read, rather than waiting for it to execute before
failing (or just silently corrupting).


> HTML attribute quoting is a source of subtle XSS vulnerabilities, so
> unquoted and backtick-quoted attributes are a corner case.

Luckily, it need not have any such security concerns in E4H, as the
parser can still tell that it's in an attribute-value context and
escape appropriately.  Since it's creating a DOM rather than text,
what quoting style you use is immediately lost anyway.

> If E4H s advertised as embedded HTML, but <><isindex></> compiles and
> behaves markedly differently than the equivalent HTML fragment, then
> doesn't it fail your understandability requirement.

Ian's point is that <isindex> itself fails the understandability
requirement - it's completely insane and not used by any modern pages.
 Getting some bizarro unexpected result out of it (because nobody
actually understands what it expands into) just to match the HTML
parser is potentially worse than doing the obvious thing which happens
to be different than the HTML parser.

>> (Essentially, auto-escaping almost by definition fails what I think is one
>> of the most important requirements of any API, in terms of security, which
>> is the "Least Surprise Property" as you call it on that page above.)
>
> I'm not just engaging in armchair philosophy about something that I've
> speced and have yet to deploy.  I have real-world experience with
> converting large projects to use this that proves you wrong.

Ian provided several examples of code where it seems like it would be
impossible to auto-escape properly, and an author relying on
auto-escaping because they've been trained that it works elsewhere
could be easily misled and inadvertently cause an XSS vulnerability.
Could you go over those and answer how you think your ideas for
auto-escaping would address the problems he raised?

~TJ

Received on Wednesday, 13 March 2013 02:34:12 UTC