Re: E4H and constructing DOMs

2013/3/11 Ian Hickson <ian@hixie.ch>:
> On Mon, 11 Mar 2013, Mike Samuel wrote:
>> >
>> > E4H is much simpler than E4X, actually:
>> >
>> >    http://www.hixie.ch/specs/e4h/strawman
>> >
>> > It's just a small syntax extension to JS. (It doesn't involve an HTML
>> > parser, in fact it doesn't involve any parser at all other than the JS
>> > parser, which is why it gives compile-time syntax checking.)
>>
>> How does it deal with XSS via CSS, URIs, VBScript, etc. without
>> involving parsers for those languages?
>>
>> What happens with
>>
>>     <><a href="{data}">Hello, World!</a></>
>>
>> when data is "javascript:doEvil()"?
>
> Exactly what you expect, you get a JS link.
>
>
>> What happens with
>>
>>     <><style>color: {data}</style></>
>>
>> when data is "expression(doEvil())"?
>
> You get some invalid CSS.
>
>
>> What happens with injection into a script?
>>
>>     <><script>var s = "{data}", re = /{data}/, x = {data};</script></>
>>
>> ?
>
> Same as with an eval and string concatenation.
>
>
> It's not magic. Magic is bad, especially around security features. Authors
> need to be able to understand the model precisely, and therefore it needs
> to be a simple model that they can easily reason about.
>
> Autoescaping mechanisms are a disaster. Simple changes to the source code
> that look like no-ops end up introducing security vulnerabilities or
> breaking the logic because suddenly the autoescaper has different context.
> Authors end up not thinking about exactly what it is they're doing,
> leading to overconfidence and injection vulnerabilities where the
> autoescaper has no idea what's going on. Backwards-compatibility means
> that mistakes in the first release of the autoescaper can't be fixed
> without opt-in, which leads to a series of "yes I really want this to be
> secure" boilerplate after a few revisions. It's just way safer to be
> explicit and have a simple model.

Ok.  So it's not a goal of E4H to be safe against XSS by default then.

> If you want to inject a string into a regular expression, you know you
> have to escape the string for regexps and then insert it. If you want to
> insert a string A into a regular expression and then insert the regular
> expression into a CSS string and then insert the CSS string into a the
> query part of a URL, you know you have to escape the string A for regular
> expressions, then escape the regular expression for CSS strings, then
> escape the CSS string for the query part of URLs. No autoescaping
> mechanism can magically know what you're doing in cases like this.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'