Preliminary Community Review: text/json

[Graham Klyne]

My apologies for not reading more closely.  Technically, I agree you have
addressed the matter, but I do feel the text, as written, doesn't sufficiently
draw a reader's attention to the problem of malformed JSON values.

Let me make a concrete suggestion this time:  after the first paragraph, I
suggest adding this:
[[
However, there is a potential security problem if an application accepts a JSON
value blindly assuming that it is safe to execute as Javascript code.
]]

This then leads to your second paragraph.

#g
--

Douglas Crockford wrote:
> The section on Security Considerations addressed this directly.
> 
>    Security considerations:
> 
>       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.
> 
>       A JSON text can be safely passed into JavaScript's eval()
>       function (which compiles and executes a string) if all of the
>       characters not enclosed in strings are in the set of characters
>       which 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 + ')');
> 
> 
> ----- Original Message ----
> From: Graham Klyne <GK at ninebynine.org>
> To: Douglas Crockford <douglas at crockford.com>
> Cc: ietf-types at iana.org
> Sent: Thursday, February 9, 2006 4:14:33 PM
> Subject: Re: Preliminary Community Review: text/json
> 
> Douglas Crockford wrote:
>> This is notice of a potential media type registration. 
>> The details may be found here:
>>
>> http://www.ietf.org/internet-drafts/draft-crockford-jsonorg-json-02.txt
>>
> 
> I have some limited experience of using JSON with TurboGears, and I think this
> registration is useful and appropriate.  I haven't read the technical spec in
> great detail, but didn't see any major problems on cursory reading.
> 
> However, I think there is an important issue that is missing from the security
> considerations:
> 
> Because JSON is a subset of Javascript, and is sometimes used as a way of
> communicating information to Javascript programs, there is a possibility for
> implementers to simply treat the JSON expressions directly as Javascript source
> code (e.g. via Javascript eval()).  This is safe if the expression is known to
> conform the the JSON specification, but if this is not checked there is a
> possibility that executable code inject side effects into a running Javascript
> program.  Therefore, applications that receive JSON expressions need to ensure
> that they are processed in such a way that ill-formed expressions have no
> possibility of causing unexpected side effects or distorting the information
> that is displayed to users.
> 
> There is one other thing I noticed.  The proposed MIME type is text/json.  I
> think that, based on comments I have seen made previously, that application/json
> would be more appropriate.  My understanding is that text/... is intended for
> textual information that is suitable for display to a general human audience;
> e.g., it has been suggested that text/html was a mistake, which should not be
> repeated.
> 
> #g
> 

-- 
Graham Klyne
For email:
http://www.ninebynine.org/#Contact