Subject: [Json] Security considerations

From: Tim Bray <[email-masked]>
Date: Sat, 5 Oct 2013 23:10:52 -0700

It dawns on me that the #1 security consideration every web programmer
learns, when using JSON, is “You could parse it with eval() but DON’T DO
THAT”. So should we include that in the -bis Security Considerations
section?

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 6 Oct 2013 10:12:21 +0200

On Oct 6, 2013, at 08:10, Tim Bray <[email-masked]> wrote:

> It dawns on me that the #1 security consideration every web programmer learns, when using JSON, is “You could parse it with eval() but DON’T DO THAT”. So should we include that in the -bis Security Considerations section?

Yes!

Phrased this way, that would be a security consideration specific to JavaScript.  It may be worthwhile pointing out that there have been attack vectors*) in other environments as well that have tried some simple, incompletely checked syntactical conversion from JSON into their own (unsafe) literal notation and loaded/executed that.

Grüße, Carsten

*) say, CVE-2013-0269, CVE-2013-0333

---

From: "John Levine" <[email-masked]>
Date: 6 Oct 2013 16:53:10 -0000

>THAT”. So should we include that in the -bis Security Considerations

I would be more concrete and note that a string that purports
to be JSON could in fact be anything, so parsers should treat
them with due scepticism.

I suppose it wouldn't hurt to spell things out for the low-clue,
and note that although it is possible to turn a JSON string into
an internal reputation by evaluating it as Java(Ecma, etc.)script,
that is exceedingly risky unless the string has been verified to
be valid JSON.

R's,
John

---

From: Matthew Morley <[email-masked]>
Date: Sun, 6 Oct 2013 14:34:56 -0400

On Sun, Oct 6, 2013 at 12:53 PM, John Levine <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

+1.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.21 (FreeBSD)
>
> iEYEARECAAYFAlJRlYsACgkQkEiFRdeC/kUpHgCfTAck4oWuM2dZlm0D2Xrbdvzk
> AzEAn1wGCFV2dBiqpoOmPmM9VDYpTdGq
> =hdOH
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>
>

-- 
Matthew P. C. Morley

---

From: R S <[email-masked]>
Date: Sun, 6 Oct 2013 15:25:37 -0700

On Sun, Oct 6, 2013 at 1:12 AM, Carsten Bormann <[email-masked]> wrote:

> Phrased this way, that would be a security consideration specific to
> JavaScript.  It may be worthwhile pointing out that there have been attack
> vectors*) in other environments as well that have tried some simple,
> incompletely checked syntactical conversion from JSON into their own
> (unsafe) literal notation and loaded/executed that.

We already have a reference to ECMAScript, and it is a pretty common case,
so it might be worth saying "eval() in ECMAScript and similar functions in
other languages..." or something like that. I believe JSON will eval in
Python as well, for example.

- Rob

---

From: John Cowan <[email-masked]>
Date: Sun, 6 Oct 2013 21:42:20 -0400

R S scripsit:

> We already have a reference to ECMAScript, and it is a pretty common
> case, so it might be worth saying "eval() in ECMAScript and similar
> functions in other languages..." or something like that. I believe
> JSON will eval in Python as well, for example.

If you arrange for "true", "false", and "null" to be defined as global
variables whose values are True, False, and None, then yes.

Note that you can validate JSON with a simple regular expression to make
it reasonably, though not 100%, safe to eval it in JavaScript.

-- 
The man that wanders far                        [email-masked]
from the walking tree                           http://www.ccil.org/~cowan
        --first line of a non-existent poem by:         John Cowan

---

From: Nico Williams <[email-masked]>
Date: Sun, 6 Oct 2013 21:03:47 -0500

> it reasonably, though not 100%, safe to eval it in JavaScript.

I'm disinclined to believe this.  Feel free to post the regex and we'll see :)

---

From: R S <[email-masked]>
Date: Sun, 6 Oct 2013 19:20:55 -0700

> variables whose values are True, False, and None, then yes.

You can.

axel-foley:dev sayrer$ python
Python 2.7.2 (default, Oct 11 2012, 20:14:37)
[GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> eval("[true, false, null]")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in <module>
NameError: name 'true' is not defined
>>> eval("[true, false, null]", {"true": True, "false": False, "null":
None})
[True, False, None]

- Rob

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 6 Oct 2013 19:37:00 -0700

<chair hat on>

> it reasonably, though not 100%, safe to eval it in JavaScript.

This document will not go there. The IETF rarely (if ever) puts on Standards Track "here is a bomb that is likely to be defused".

It really isn't necessary in this case to add JavaScript-specific code, much less code that might be unsafe.

--Paul Hoffman

---

From: Tim Bray <[email-masked]>
Date: Sun, 6 Oct 2013 20:18:33 -0700

On Sun, Oct 6, 2013 at 7:37 PM, Paul Hoffman <[email-masked]> wrote:

> This document will not go there. The IETF rarely (if ever) puts on
> Standards Track "here is a bomb that is likely to be defused".
>

You mean will not cover might-make-you-safe regex, or will not warn of the
dangers of eval()?

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 6 Oct 2013 20:19:26 -0700

On Oct 6, 2013, at 8:18 PM, Tim Bray <[email-masked]> wrote:

> You mean will not cover might-make-you-safe regex, or will not warn of the dangers of eval()?

Correct.

--Paul HOffman

---

From: John Cowan <[email-masked]>
Date: Sun, 6 Oct 2013 23:23:29 -0400

> I'm disinclined to believe this.  Feel free to post the regex and we'll see :)

See <https://github.com/douglascrockford/JSON-js/blob/master/json2.js>.

-- 
La mayyitan ma qadirun yatabaqqa sarmadi                            John Cowan
Fa idha yaji' al-shudhdhadh fa-l-maut qad yantahi.              [email-masked]
                --Abdullah al-Hazred, Al-`Azif      http://www.ccil.org/~cowan

---

From: Tim Bray <[email-masked]>
Date: Sun, 6 Oct 2013 21:09:00 -0700

What is the argument against including a conventional warning against a
plausible-but-dangerous practice?  The only one I can think of is “everyone
already knows that” which doesn’t seem very strong to me.

---

From: R S <[email-masked]>
Date: Sun, 6 Oct 2013 22:02:13 -0700

> already knows that” which doesn’t seem very strong to me.

It's worse than that.

RFC 4627 has text that says a JSON string can be passed to eval() if it
passes an inadequate regex. This text should be corrected, not just
omitted.

- Rob

>
> On Sun, Oct 6, 2013 at 8:19 PM, Paul Hoffman <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>
> > wrote:
>
>> On Oct 6, 2013, at 8:18 PM, Tim Bray <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>>
>> wrote:
>>
>> [email-masked] <javascript:_e({}, 'cvml', [email-masked]');>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 07 Oct 2013 16:31:10 +0900

I think it would be good to say something like "There are regular 
expressions floating around with the claims that they can pre-check a 
JSON text and make it safe to pass it to eval() and friends, but none of 
these are actually work."

I think it would be a bad idea to say something like "Here is a regular 
expression which almost works."

Regards,    Martin.

Off-topic:

I think that the regular expression engine in Ruby 1.9 (Oniguruma) comes 
with features that allow the creation of a Regexp object that would do 
the full job. That's because these regular expressions essentially are 
powered up to reach the level of context-free languages.

Of course, from a viewpoint of formal language theory, they don't 
deserve to be called regular expressions anymore, but then this applies 
to virtually all of the "regular expression" implementations in today's 
languages and libraries.

On 2013/10/07 13:09, Tim Bray wrote:
> On Sun, Oct 6, 2013 at 8:19 PM, Paul Hoffman<[email-masked]>  wrote:
>
>> On Oct 6, 2013, at 8:18 PM, Tim Bray<[email-masked]>  wrote:
>>