Re: E4H and constructing DOMs

On Tue, 12 Mar 2013, Mike Samuel wrote:
> >
> > What would be autoescaped in something like:
> >
> >    h`<img src="${scheme}://${host}:${port}/${path}/${file}.${ext}"
> >          srcset="${file1} ${w1}w ${file2} ${w2}w"
> >          alt="${alt}"
> >          data-logger-url="logger?id=${id}&key=1234">
> >
> > Or this:
> >
> >    x`<div style="color: ${colorModeA}"
> >           data-style-mode-a="color: ${colorModeA}"
> >           data-style-mode-b="color: ${colorModeB}"
> >           data-style-mode-c="color: ${colorModeC}"></div>`
> >
> > ...where script switches in the new style="" attribute values dynamically
> > based on e.g. some game state?
> >
> > How about this:
> >
> >    x`<img width="${width}"
> >           src="${profile.cgi?username=${username}&size=${width}}">
> >      <script>
> >       var x = new Image(${width});
> >       x.src = 'profile.cgi?username=${username}&size=${width}';
> >      </script>`;
> >
> > How about:
> >
> >    x`<p>Paste this WLAML command: AB=2%\*2*11*22;GA=${GADATA}*41</p>`
> 
> https://developers.google.com/closure/templates/docs/security#in_urls 
> gives, in tabular form, examples of contexts and the escaping 
> conventions used.
>
> You can try out examples in one of the testbeds.

The answer seems to be "they are all a disaster". They paper over some of 
the mistakes, corrupts the results for some of the others, and mislead 
authors into thinking the remainder are safe.


> >> What do you and Adam mean by "safe" when you say "safe by default"?
> >
> > I was just using it in the way that you used it. I would be fine with 
> > not using the term at all.
> 
> It's quite possible that we have been talking past one another because 
> we have very different attack models in mind. If you think we're using 
> the same definition, what do you think I mean by "safe"?

I'll let you define your own terms.

What I care about is having APIs that are predictable, understandable, and 
simple, where it is straight-forward to use them in a manner that exhibits 
good coding practices.


> >>> provide compile-time syntax checking for in-script DOM tree creation
> >>
> >> Contextual auto-escapers provide some level of this.
> >
> > I haven't seen any proposal that requires browsers to fail to compile 
> > code that contains syntactically incorrect fragments. Do you have an 
> > example of what you mean? Which proposal does that?
> 
> I'm not proposing a contextual autoescaper specification.

Then your solution doesn't provide this.


> I am merely proposing string templates which enable, among other things, 
> easy integration of contextually auto-escaped applications.

Not compile-time checked ones, right?


> I think specifying a blessed template language is premature so I think 
> enabling experimentation is the best course for now.

I think we've done a lot of experimentation already.


> >> > [...]
> >> >     * avoid using the HTML parser
> >>
> >> I understand the first two goals.  The last seems to be confusing a 
> >> design choice with a design goal since not using an available tool is 
> >> rarely something of direct benefit to the end user.
> >
> > The HTML parser is an utter disaster. It's slow, it's big, it's 
> > ridiculously complicated. It does stuff you'd never guess at without 
> > an intimate knowledge of the requirements. Using it is not a feature.
> 
> One of the things that I've been building into my grammar driven 
> approach is to allow explicit marking of ways to coerce content written 
> using grammatical corner cases to the subset of the grammar that is 
> consistently well-handled -- so the template language automatically adds 
> quotes around unquoted attributes, end tags, etc.
> 
> It should be possible for a template language to allow (but warn) on 
> messy input but to produce strings that are both valid XML (modulo 
> doctypes, raw text content, and HTML character references) and valid 
> HTML.  I don't yet have good test-coverage or experience with this.

I don't understand what you're saying here. The "corner cases" in HTML 
aren't "unquoted attributes" and so forth. They're crazy things like 
"<image>" create an "img" element, "</br><br>" creates two "br" elements, 
"</p><p>" creates more "p" elements than "<p></p>", "<table><input>" 
creates two siblings while "<table><input type=hidden>" creates a 
parent/child relationship, "<isindex prompt>" creates half a dozen nodes 
including multiple text nodes and elements, though none of them with the 
tag name "isindex", and the output even has an attribute, though it's not 
called "prompt", "<script>" having all kinds of wacky interactions with 
the event loop, crazy things happening with association of form controls 
to form elements, elements being literally moved in the DOM as the DOM is 
created... the list of crazy behaviours is long and esoteric.


> >> >  - to have good security characteristics:
> >> >     * provide a model that is conceptually simple
> >> >     * allow arbitrary strings to be embedded in DOM trees in a way that
> >> >       does not allow arbitrary elements or attributes to be created
> >>
> >> If even
> >>     <a href="{...}">
> >> is a foot gun then I think it fails at this goal.
> >
> > Which goal does it fail? The model is simple, and you can't create
> > arbitrary elements or attributes. Obviously if you're inserting a string
> > into a context where it will be parsed, you have to make sure it's valid
> > data, but whitelisting like that is elementary, and applies in all cases,
> > including many where there's just no way you could autoescape because the
> > data/syntax you're inserting into is app-specific.
> 
> It fails to preserve the "code-effect property" as outlined at
> https://js-quasis-libraries-and-repl.googlecode.com/svn/trunk/safetemplate.html#code_effect_property

You said it fails at "this" goal, citing the goals above. They don't 
include preserving the code-effect property. I don't think it's a good 
idea to preserve that, as that essentially boils down to magic.

The way you get secure code is by having authors understand exactly what 
is happening with their data, and having the authors make sure that they 
follow a disciple where they think of their data as being in specific 
types, and when they use the data, they first convert it to be a valid 
value to insert into the type of whatever they are inserting the data 
into. E4H makes this easy: the context of any substitution is "text of the 
type that is appropriate in this place in the DOM", which is a net 
improvement over string concatenation where the context is "markup at this 
place in HTML syntax", a significantly more complicated type to reason 
about. This is why it is a better solution to creating DOMs than solutions 
that rely on string concatenation followed by application of the HTML 
parser, which is the only way these days to do DOM creation tersely.


(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.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 12 March 2013 23:49:40 UTC