[cap-talk] solve CSRF by making references unforgeable, not unshareable

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Tue Mar 31 22:02:43 EDT 2009


James A. Donald wrote:
> James A. Donald wrote:
>>> It appears to me that jsonml is exactly as vulnerable
>>> to injection attacks as sql.
>>>
>>> The server generates jsonml code for the client to
>>> execute in the same way as it generates sql code for
>>> the database to execute.
> 
> David-Sarah Hopwood wrote:
>> No, the whole point is that the server doesn't munge
>> text; it generates a JsonML data structure with the
>> intended structure and then encodes that structure as
>> text. This avoids the injection vulnerabilities that
>> could occur if it tried to construct the string by
>> concatenation, without proper quoting.
> 
> My understanding is different:
> 
> A DOM, and only a DOM, is "a data structure with the
> intended structure"
> 
> JsonML does not have data structures.

This is way too pedantic even for me. It is obvious what data
structure I was referring to: the AST form of JsonML, represented
as nested lists.

> JsonML is just a
> text string that can be converted to and from xml and to
> and from a DOM.

JsonML is a convention that describes both a list-based AST
structure, and a serialization of that structure (the latter
being just the JSON/JavaScript serialization).

> To generate injection proof JsonML, it has to be
> generated at run time from a DOM

No, that's not necessary. If it is generated from the corresponding
JsonML AST, there are no plausible injection attacks.

> - but there is no run time DOM on the server side.
> 
> What one has is javascript code for building a DOM from
> JsonML code. Typically this javascript code is compiled
> from a JBST template.  The JsonML code may be based on a
> build time DOM - but is going to be modified in
> inserting the run time data.

If you're suggesting that a programmer would try to splice some
other string into an existing JsonML string, why on earth would
they do that? Programmers are lazy; they will do the obvious thing,
which is to reencode the AST. If they attempt to splice strings,
then that's not the pattern that I recommended or asserted to be
injection-resistant.

> There is no run time guarantee that this JsonML code
> will not contain a little Bobby tables.
> <http://tinyurl.com/cqfg6h>

(Yes, I'm a huge fan of xkcd. You should use the permanent link, though:
<http://xkcd.com/327/>.)

If you insist, let's see why that specific attack would fail when using
ASTs:

  var littleBobby = "Robert'; DROP TABLE Students; --";
  var ast = {command:"INSERT INTO", table:Students, columns:["name"]};
  ast.values = [littleBobby];
  submitToDatabase(ast);

An injection attack is prevented because the only string splicing
is done within the relied-on 'submitToDatabase' API, not by the
application on a per-query basis. In order for that API to allow any
attack, it would have to get JSON encoding in general wrong, which is
not an injection attack.

-- 
David-Sarah Hopwood ⚥



More information about the cap-talk mailing list