Re: [Json] Nested JSON encoding style too likely to be insecure

Phillip Hallam-Baker <ietf@hallambaker.com> Tue, 23 February 2016 05:54 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C0B1ACD1C for <json@ietfa.amsl.com>; Mon, 22 Feb 2016 21:54:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJyG9YA21ViH for <json@ietfa.amsl.com>; Mon, 22 Feb 2016 21:54:20 -0800 (PST)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A90BD1ACEB6 for <json@ietf.org>; Mon, 22 Feb 2016 21:54:19 -0800 (PST)
Received: by mail-lf0-x22c.google.com with SMTP id l143so108472886lfe.2 for <json@ietf.org>; Mon, 22 Feb 2016 21:54:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=3SDYOb66To7p52eDx6wi8Denn/KHfbsmfayvF94fzH4=; b=gqMQBfblgpGXC+SDemtEd1IVXNXe62O2HAxGfWy4eqcynLWEikJdfI/YlobZq/nDKz rhWUJu1ve14OJ6wx+U0RJsctWbziy58W2g/1s7dJDXkbmY2HylzaQYqX30v8XlilGDVb MjRKAqFO+HXzz+2xrr8VQZF61J/pkeMQpFfg7L3S7UcwXzYFnYk4YigqnednLu8mhj4h qFtA/XeOi90sObonnc/VDPMJs7aZlpmSS1b7cdchDh9rR1cLD9BHXGOeXDf/gLO9aErV S7Hf9ULIY1zzVFHPHSVetksIiBkP5BwH3XSvXuzn6OvEstU862mLgZr2OvvsMGnnTtM5 9q5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3SDYOb66To7p52eDx6wi8Denn/KHfbsmfayvF94fzH4=; b=TvCGOhX9vlJ9a47b7mvo4d+R8oXsWa/5WG2i0Ai+sySzfgphGj1IvpzGMfN8Fehx7X 4yCpZLGGgZ6T8i9fEXUn5LlZQxTj68zeUlRuJi79TtDYbX3vOefn7yQoPfoJwaN3iH/A hBuuVjQQTSu9JPWiyPXUZZams42y+uDV2qEwTCx7/cY8BKMgdDbtU/YQyL4Dt/+CbAVr Se9SGqnTaRDYVV418kIexKZtjo3yVdDMQE1D8rRJNWABMMutgacCDy0mh7wpXFFl09sj uA5p6lwM1Vr0LfN3tnCmpl+DujAyy3oH9GqzDDUlItnhEGrcerKFuGehzJE0d2iJZQ3A BTAg==
X-Gm-Message-State: AG10YOQaxGlB2vHJ0mN0ViDduK+5d2uGMqH+E0GLmdxxb62o5iDGYA6clyOHjvXjYni/LORPhx1JEuBkLFQb9w==
MIME-Version: 1.0
X-Received: by 10.25.205.7 with SMTP id d7mr11700571lfg.70.1456206857900; Mon, 22 Feb 2016 21:54:17 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.49.80 with HTTP; Mon, 22 Feb 2016 21:54:17 -0800 (PST)
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BBADBF674@WSMSG3153V.srv.dir.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E13BBADBF674@WSMSG3153V.srv.dir.telstra.com>
Date: Tue, 23 Feb 2016 00:54:17 -0500
X-Google-Sender-Auth: 0qJYXTijqOXASLX6ODUR1i7vcpQ
Message-ID: <CAMm+LwjwWEmJqcicdwZ+fE3+XMamoDF8RfCMLRz75MpFB=tiWg@mail.gmail.com>
From: Phillip Hallam-Baker <ietf@hallambaker.com>
To: "Manger, James" <James.H.Manger@team.telstra.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/json/R4k_NlWOVe6wQCeezvaFo1ifug8>
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Nested JSON encoding style too likely to be insecure
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 23 Feb 2016 05:54:21 -0000

On Tue, Feb 23, 2016 at 12:49 AM, Manger, James
<James.H.Manger@team.telstra.com> wrote:
> I’m a bit late to the party on the “On flat vs nested JSON encoding style”
> thread…
>
>
>
> The nested style that Phillip was encouraging is:
>
>
>
> { "A" :
>
>    { "field1" : "value1", "field2" : "value2", "field3" : "value3" } }
>
>
>
> It looks like messages in this style (requests and responses) would always
> have a top-level JSON object with a single member identifying the type of
> message (“A” in this example). An app might get this member from an iterator
> over the object (eg in Java when using a Map to represent a JSON object: op
> = map.entrySet().iterator().next();).
>
>
>
> But what happens if a message (maliciously) has two elements in the
> top-level object?
>
>
>
> { "READ" :
>
>    { "field1" : "value1", "field2" : "value2", "field3" : "value3" },
>
>   "DELETE":
>
>    { "field1" : "value1", "field2" : "value2", "field3" : "value3" } }
>
>
>
> A receiving app (expecting 1 element) could easily pick either “READ” or
> “DELETE” and ignore the other. If an authorization layer picks “READ” and
> allows the message through, then the backend picks “DELETE” and acts
> accordingly… ouch.
>
>
>
> This nested style looks cute, but is probably too cute as “obvious” ways to
> implement it can easily be insecure.
>
> If we want to ensure a message type to come before its content then we
> should use a JSON array: [type, content].

You need to limit the toplevel to one element. That is fairly easy to do though.