Re: [Json] Go JSON parser ignores the case of member names

John Cowan <> Wed, 09 March 2016 01:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 64CA712DD18 for <>; Tue, 8 Mar 2016 17:20:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.202
X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1KOXyRWu3xcm for <>; Tue, 8 Mar 2016 17:20:33 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2FEBD12DD12 for <>; Tue, 8 Mar 2016 17:20:33 -0800 (PST)
Received: from cowan by with local (Exim 4.72) (envelope-from <>) id 1adSnc-0004L3-6v; Tue, 08 Mar 2016 20:20:28 -0500
Date: Tue, 8 Mar 2016 20:20:28 -0500
From: John Cowan <>
To: "Manger, James" <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.20 (2009-06-14)
Sender: John Cowan <>
Archived-At: <>
Cc: "" <>
Subject: Re: [Json] Go JSON parser ignores the case of member names
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Mar 2016 01:20:34 -0000

Manger, James scripsit:

> I noticed that the default JSON parsing in the Go language
> basically ignores the case of member names. Do JSON experts see this
> case-insensitive parsing as a useful convenience for programmers (being
> lenient with what you receive), or as a bad insecure design choice?

I see it as Very Bad Indeed.  It violates the RFC and, as you say, causes
a JSON text to be interpreted one way by one recipient and another way
by another.

> This looks quite diabolical for security as it is trivial to create
> valid JSON values that will be interpreted differently by different
> implementations. I would expect most implementations (that are expecting
> an "alg" member) to see its "HS256" value and simply ignore the extra
> "ALG" member. 

The Right Thing is to _validate your JSON_.  Make sure what you expect
is there *before* acting on it, and if not *don't act on it*.

John Cowan
My confusion is rapidly waxing
For XML Schema's too taxing:
I'd use DTDs / If they had local trees --
I think I best switch to RELAX NG.