Re: jsonb, unicode escapes and escaped backslashes - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: jsonb, unicode escapes and escaped backslashes
Date
Msg-id CAM3SWZSyHSpxBQvupYNnOO6CAqZWpONA6v4JNvL1hQWY2P9a0A@mail.gmail.com
Whole thread Raw
In response to Re: jsonb, unicode escapes and escaped backslashes  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: jsonb, unicode escapes and escaped backslashes
List pgsql-hackers
On Wed, Jan 28, 2015 at 9:36 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Anyway, there is a significant amount of work involved here, and there's
> no way we're getting it done for 9.4.1, or probably 9.4.anything.  I think
> our only realistic choice right now is to throw error for \u0000 so that
> we can preserve our options for doing something useful with it later.

+1

I looked into it, and it turns out that MongoDB does not accept NUL in
at least some contexts (for object keys). Apparently it wasn't always
so. MongoDB previously had a security issue that was fixed by
introducing this restriction. Their JSON-centric equivalent of
per-column privileges was for a time compromised, because "NUL
injection" was possible:

https://www.idontplaydarts.com/2011/02/mongodb-null-byte-injection-attacks/

It's easy to bash MongoDB, but this is still an interesting data
point. They changed this after the fact, and yet I can find no
evidence of any grumbling about it from end users. No one really
noticed.

I agree that the restriction on NUL is consistent with the design of
JSONB. Disallowing all bytes invalid in the current encoding with the
sole exception of NUL was a mistake, IMV.
-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Matt Kelly
Date:
Subject: Re: Exposing the stats snapshot timestamp to SQL
Next
From: Tom Lane
Date:
Subject: Re: jsonb, unicode escapes and escaped backslashes