Re: Preliminary Community Review: text/json

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@ninebynine.org> To: Douglas Crockford <douglas@crockford.com> Cc: ietf-types@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

It seems that it would be better for JSON to be in application rather text. As the document says, it is a portable representation of structured data, ie not meant for human consumption even if it happens that a human can makes some sense from it. RFC 3023bis, if it sees the day of light, will deprecate the use of text/xml for that same reason. Philippe On Thu, 2006-02-09 at 16:21 -0800, 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@ninebynine.org> To: Douglas Crockford <douglas@crockford.com> Cc: ietf-types@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

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@ninebynine.org> To: Douglas Crockford <douglas@crockford.com> Cc: ietf-types@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
participants (3)
-
Douglas Crockford
-
Graham Klyne
-
Philippe Le Hegaret