Re: E4H and constructing DOMs

2013/3/8 Adam Barth <w3c@adambarth.com>:
> tl;dr: No one is disputing that string templates as currently designed
> are insecure by default and will lead authors to write code filled
> with XSS vulnerabilities.  I recommend removing string templates for
> the spec until these security issues are resolved.

I oppose this on the grounds that it is better than current ad-hoc
content creation practices, and can lead to a principled solution in a
way that AST approaches cannot.

> (Consolidating replies---responses inline.)
>
> On Thu, Mar 7, 2013 at 6:36 PM, Rick Waldron <waldron.rick@gmail.com> wrote:
>> On Thu, Mar 7, 2013 at 9:15 PM, Adam Barth <w3c@adambarth.com> wrote:
>>> Linking to a thousand-line JavaScript library as evidence that string
>>> template can be used securely pretty much proves my point: it's hard
>>> to use string templates securely.  That means that most authors won't
>>> use them securely and will write code that's full of XSS.
>>
>> I'd like to kindly ask that you stop approaching this conversation as though
>> browsers and the web are the only client of the EcmaScript specification.
>> The language serves to provide primitives that can be used to compose higher
>> level abstractions, eg. DOM APIs with whatever level of security the domain
>> problem requires.
>
> That's a nice strawman, but I'm not approaching this conversation as
> through browsers were the only clients of ECMAScript.  What I'm saying
> is that the current design is insecure when used in browsers and
> because browsers are a large user of ECMAScript, we shouldn't include
> a language feature that gives web authors a giant security footgun.
>
> On Thu, Mar 7, 2013 at 7:40 PM, Mark S. Miller <erights@google.com> wrote:
>> Hi Ian, this seems a misunderstanding or non-sequitur. Mike and Rick's point
>> is not to compromise, it is to do something solid and general purpose, to
>> avoid injection bugs in a variety of DSL scenarios, not just HTML. Even in
>> the browser, JS is sometimes used to compose SQL that is sent to the server.
>> It isn't the browser's business to understand SQL, but we can provide a
>> mechanism that is as useful for SQL, again, without compromise.
>
> String templates, as currently designed, are bad for constructing SQL
> statements too.  When used in their default mode (which is the most
> common way that authors will use them), they lead to SQL injection
> vulnerabilities.  Instead, we should use an approach analogous to
> prepared statements, which are much less likely to lead to SQL
> injection.

>> Adam, I think you miss the point of Mike's message rather completely. This
>> thousand line JS library has to be done for HTML once, not once per usage.
>> It is complicated because HTML is complicated. And the amount of code
>> compares quite favorably to the browser's HTML implementation, which is much
>> more security critical than this. In any case, if the HTML quasi-parser is
>> provided by the browser platform as standard equipment, it can probably
>> reuse some of the browser's existing mechanisms, to help keep these two HTML
>> systems in sync.
>
> It doesn't matter how many times the library needs to be authored or
> by whom.  If we need a thousand lines of JavaScript to compensante for
> the by-design insecurity of string templates, then we've failed as
> language designers.  Instead, ECMAScript should have a templating
> system that is secure-by-design and by default instead of
> insecure-by-design-and-default-but-can-be-patched-with-a-thousand-line-library.

You simply do not have the power to force people to write secure code by fiat.

JavaScript will have string concatenation via the (+) operator
regardless of whether string templates are in the language or not and
whether or not E4H or some other AST approach were speced and ready to
ship.

A language feature only contributes to security if it's used instead
of insecure methods.

If we are, as I believe we both want to, make a dent in the morass of
XSS produced by the PHP set then we need
1. something that is easy to migrate to from ad-hoc approaches,
preferably piecemeal.
2. something that can provide provable guarantees
3. something that is syntactically more attractive (e.g. due to
expressiveness, succinctness)


>> As for whether the output of the HTML quasi-parser is an AST or an encoded
>> string, that is up to the quasi-parser designer. The quasi-literals in E
>> generally generated ASTs. Mike convinced me he can generate encoded strings
>> directly as safely and faster, if the point is to eventually produce an
>> encoded string. I'm happy either way. Both decisions are perfectly
>> compatible with the design on quasis, er, template strings, as speced in
>> draft ES6.
>
> That's nice, but the default mode for string templates works for HTML
> but is insecure.  That means authors will write code filled with XSS
> because they'll just use the default mode.

Unless the default mode can be overridden within a scope via a single
line of code.

I have experience with changing the semantics of a template language
with a large extant codebase (Google+) to use contextual
auto-escaping.

> What you've written in this paragraph is even more scary.  You're
> saying that string templates are so poorly designed that they guided
> you, a world-renowned security expert, into using an extremely complex
> (and therefore unlikely to be secure) design.  Surely authors who are
> not world-renowned security experts will fare even worse.

That you have not made an effort to understand the approach does not
mean that it is "extremely complex" but even if you did engage with
our actual arguments, this would still be wrong.
Any AST approach that is going to work is going to similarly require
encoders if it is to do any of the following:
1. Handle embedded content without rewriting the DOM to not use DOMString
2. Allow content to be serialized for storage or cross-frame communication.
3. Be usable in the absence of a browser.


> On Thu, Mar 7, 2013 at 7:57 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Thu, Mar 7, 2013 at 5:55 PM, Mike Samuel <mikesamuel@gmail.com> wrote:
>>> That doesn't apply since this is not parsing, it is lexing, and
>>> regular expressions can be used to lex HTML.
>>
>> Actually, no you can't. For example the lexing of contents of <script>
>> elements is quite complex.
>
> It's mathematically impossible.  You need a stack to keep track of the
> foreign content mode (i.e., whether we're tokenizing HTML, SVG, or
> MathML).  Without that information, you can't tell who the tokenizer
> will parse apparent CDATA sections.


> On Thu, Mar 7, 2013 at 8:36 PM, Mike Samuel <mikesamuel@gmail.com> wrote:
>> I talk about different kinds of developers (library authors,
>> application authors) writing code and you say things that suggest to
>> me that you think the bulk of web developers are going to be writing
>> large amounts of security-critical code.
>> In your view, who is writing what code with the string templates approach?
>
> It doesn't matter who writes the thousand-line library.  The fact that
> you need a thousand-line library to use string templates securely
> (even assuming that the library is correct!) demonstrates that the
> design itself is insecure and should not be part of ECMAScript.
> Instead, we should design a templating system that doesn't need a
> thousand-line library to be used securely.

Why should we deploy such a secure templating system as part of the
language and not as a library?
What if we spec something secure and get it wrong?

What you keep calling a 1k line library is a strawman too.  You ignore
that I am actually advocating a grammar-driven approach.  You can
dismiss that without taking the effort to understand it, but you
cannot do that and claim that an insecurable AST approach is
preferable to it.


>> Under the AST model, who is writing what code?  What portion of an AST
>> approach needs to involve spec-producing committees?
>
> I'm not advocating E4H, but as an example, in E4H no one needs to
> write a thousand-line library.  The spec itself is two printed pages:

> http://www.hixie.ch/specs/e4h/strawman
>
> I'm not claiming that E4H is secure is all cases.  I'm just claiming
> that the "hello, world" template is secure by default.  For string
> templates, the "hello, world" template is XSS.

E4H is simple and wrong.  It does not deal with embedded languages.
It also is not a good migration target for existing code.

>> What is your exemplar of the AST model (if not Yesod) and what is your
>> plan to cause the bulk of web programmers to do things using an AST
>> approach instead of using ad-hoc string approaches?
>
> Personally, my favorite AST-style template system is Haml because the
> templates themselves are beautiful.  I don't think we should include
> Haml in EMCAScript as-such because Haml has a bunch of Ruby-ism (e.g.,
> self-quoting strings for attribute names).  I believe we could come up
> with something similar to Haml that felt like a natural extension of
> ECMAScript.

> The above paragraph is somewhat off topic.  At the moment, I'm arguing
> that we should remove string templates from the spec because they are
> insecure.  Once we do that, we can have a discussion about what to
> replace them with.  (I imagine that discussion will take a fair bit of
> time since there are many details that people will want to bikeshed.)

My argument is that we need to produce minimal language extension
points to allow experimentation by security researchers.


> On Thu, Mar 7, 2013 at 9:59 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> I thought that one of the points with quasis was that they would allow the
>> above to be interpreted such that firstName and lastName was inserted as
>> text content. I.e. the quasi handler could avoid parsing the contents of
>> those values as HTML and instead just inset them as text content.
>
> In my example, I used string templates (aka quasis) in their default
> mode, which is insecure, hence my claim that string templates are
> insecure by default.  Mike Samuel claims that he has written a
> safeHTML quasis handler, which takes about a thousand lines of
> JavaScript, hence my claim that string templates are difficult to use
> securely.



>> This would mean that the HTML quasi would by default be resilient against
>> HTML-injection.
>
> Even if we had a secure HTML quasi handler, the HTML quasi handler
> would not be the default handler.  That means the templating system is
> insecure by default.
>
>> To supplement this behavior we could allow the quasi to take special values
>> which would be passed to the HTML parser "like normal" and thus be parsed.
>> I.e. something like
>>
>> HTML`<h1>Welcome ${ asUnsafeHTML(firstName) } ${ lastName }!</h1>`
>>
>> In this case the asUnsafeHTML function would return an object which was
>> recognized by the HTML quasi as "should be parsed" and would contain a
>> property which holds the string value passed in the first argument.
>>
>> Since no parsing would take effect at the asUnsafeHTML callsite, and instead
>> would happen while the rest of the quasi was parsed, all of the normal
>> contextual parsing rules would apply.
>>
>> This way the quasi should by default be as safe as an AST template system,
>> while allowing the page to opt in to more feature full, less safe
>> templating.
>>
>> We could even provide functions like asSafeHTML which would trigger the
>> quasi to parse that piece of content using rules that prevent only "safe"
>> elements.
>
> None of the above solves the problem that string templates as
> currently designed are insecure by default and will lead authors to
> write code filled with XSS vulnerabilities.
>
> Adam
>

Received on Friday, 8 March 2013 21:28:12 UTC