Re: [apps-discuss] Guidance on RFC 4627 as reference

[Julian Reschke <[e-mail]>]

On 2012-09-20 20:44, Phillip Hallam-Baker wrote:
> The issue here that the RFC seems to hint at (the language is next to
> meaningless) is that JSON does not provide the types of integrity
> checking that should be used if you are using it to wrap something like
> SQL commands or other data to be passed to a scripting language.
> ...

WHICH language?

As far as I can tell, the spec describes how to pass names strings, 
numbers and boolean around. It doesn't care at all what you put into 
strings (and it shouldn't).

> There are encodings that are explicitly designed to make that type of
> use safe and there are ways of applying JSON that can make it safe but
> JSON does not provide an automatic check.

Automatic checks of what? Strings are strings are strings. What do you 
want to check?

> If that is not the issue that the SC section is trying to explain then
> lets have someone else try to explain what the SC in the media type
> registration means.

It says:

>    Generally there are security issues with scripting languages.  JSON
>    is a subset of JavaScript, but it is a safe subset that excludes
>    assignment and invocation.

That sounds pretty clear to me.

>    A JSON text can be safely passed into JavaScript's eval() function
>    (which compiles and executes a string) if all the characters not
>    enclosed in strings are in the set of characters that form JSON
>    tokens.  This can be quickly determined in JavaScript with two
>    regular expressions and calls to the test and replace methods.
>
>       var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
>              text.replace(/"(\\.|[^"\\])*"/g, ''))) &&
>          eval('(' + text + ')');

These are instructions how to prevent a a Javascript code injection in 
case you choose to use the JS eval() function to parse the JSON.

Best regards, Julian