Re: [Json] Security Considerations

Stefan Drees <stefan@drees.name> Fri, 07 June 2013 07:26 UTC

Return-Path: <stefan@drees.name>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E0321F93F8 for <json@ietfa.amsl.com>; Fri, 7 Jun 2013 00:26:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id im8JqKGvWqad for <json@ietfa.amsl.com>; Fri, 7 Jun 2013 00:26:24 -0700 (PDT)
Received: from mout.web.de (mout.web.de [212.227.15.14]) by ietfa.amsl.com (Postfix) with ESMTP id 44F3321F9473 for <json@ietf.org>; Fri, 7 Jun 2013 00:26:24 -0700 (PDT)
Received: from newyork.local.box ([93.129.186.5]) by smtp.web.de (mrweb103) with ESMTPSA (Nemesis) id 0M1GAG-1UVNZv0CIy-00tbNY; Fri, 07 Jun 2013 09:26:23 +0200
Message-ID: <51B18B1E.30805@drees.name>
Date: Fri, 07 Jun 2013 09:26:22 +0200
From: Stefan Drees <stefan@drees.name>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Douglas Crockford <douglas@crockford.com>
References: <51B0E02E.4070209@crockford.com>
In-Reply-To: <51B0E02E.4070209@crockford.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V02:K0:w2zcjuSynolS7zL91evVsjdPa1xj1nQ0p5SDU4nkNk1 bQIUaiWYq05CBOSbnBcIJeLzz9DLOW6Lq0fXy2TVY8MV+pOAch kaQ8wwT1f6o5HaGhLhXx2P+i5kcDV8VVMhziHhTfOyCasg6GoW tVhBiuDHToGH3vnz2eLR+GDjgiiauWdDOFKEOHjLa9pX5bIJhD q2UH/owzIOV0necXhefvg==
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Security Considerations
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stefan@drees.name
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jun 2013 07:26:30 -0000

On 06.06.13 21:17, Douglas Crockford wrote:
> Proposal:
>
>     ...
>
>     JSON is so similar to some programming languages that the native
>     parsing ability of the language processors can be used to parse JSON
>     texts.  This should be avoided because the native parser will accept
>     code which is not JSON.
>
>     For example, JavaScript's eval() function is able parse JSON text,
>     but is can also parse programs.  If an attacker can inject code into
>     the JSON text (as we saw above), then it can compromise the system.
>     JSON parsers should always be used instead.

as JSON allows '{"\/":null}' this already forbids any native parsing 
ability of C like (or "based") languages including Python ;-)

I think these paragraphs are a very good change, but might ripen even 
more through discussions.

For me the main points of data interchange and in sequence are:

1. Do not parse any untrusted data without preconditioning

2. Do not excecute/eval untrusted data

and trust is sometimes hard to establish ...

As long as these two points stand out and are not burried inside sample 
language terms, I am happy with any re-phrasing.

Stefan.