Pseudo-JSON with unquoted property names

David-Sarah Hopwood david-sarah at jacaranda.org
Fri Jun 5 20:14:40 PDT 2009


Mark S. Miller wrote:
> On Fri, Jun 5, 2009 at 5:07 PM, Brendan Eich <brendan at mozilla.org> wrote:
> 
>> Do Doug and Mark share your risk-of-perpetuating-eval analysis?
> 
> I think the logic of David-Sarah's argument is sound, but I do not agree
> with the conclusions.

So you must disagree with the premises ;-)

> The security of those who do switch to the new JSON
> api is unaffected by the continued use of eval by others. Given the sparsity
> of examples found so far,

I did not try particularly hard to look for more examples.

> I'd guess that most of those who continue to use
> eval for the reasons David-Sarah mentions will continue to use eval even if
> we change JSON to operate as he suggests. There's really not much we can do
> to improve the security of code that isn't maintained.

It wasn't unmaintained code that I'm concerned about; I completely agree
with you about that. On the contrary, I am assuming that the code in
question is maintained well enough for someone to consider switching to the
JSON2 API (or using it to start with in the case of new code). However,
I am *not* assuming that security is a particularly high priority in the
eyes of that maintainer (because it usually isn't), and I am also not
assuming that they are a skilled programmer.

If they know that they can *very easily* switch to or use the JSON2 API,
simply by using "JSON.parse(s)" instead of "eval('('+s+')')" (and adding
<script src="json2.js"> so that this works on existing browsers), and
have a high degree of confidence that this will Just Work, then they
might do so.

But suppose this doesn't work immediately because the source of the JSON
is nonconformant, in one of the more common ways. The maintainer may or
may not have the ability to change that source, but that takes effort
(more effort than changing a few API calls in the consumer), and in many
cases they will not be responsible for maintaining that part of the overall
system's code. So they're just as likely to say "Sod it, I'll just revert
that change", and continue to use eval. Or else they hear of
interoperability problems that other people have had with the JSON2 API,
and don't attempt to switch to it at all.

I am well aware that there is a slippery slope down which we might slide
by trying to accept other nonconformant JSON that would have been accepted
by eval. I'm only suggesting to go a *little* way down that slope, by
tolerating only the nonconformances that are most common in practice, and
then hammer in the pitons.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com



More information about the es5-discuss mailing list