incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Alfke <>
Subject Re: Duplicate fields in documents
Date Thu, 20 Feb 2014 23:08:11 GMT

On Feb 20, 2014, at 10:40 AM, Paul Davis <> wrote:

> To me, the answer to the original email in this thread is "If you
> don't want duplicate keys in your JSON, don't put duplicate keys in
> your JSON". Given that this is the first time I've actually seen this
> as a user reported error I think that guidance has served users quite
> well.

The thing that bothers me about this scenario is that you end up with a document stored in
the database, which can be interpreted differently by different clients.

For example, you PUT a doc whose JSON contains "… "color":"blue", "color":"green", …
Now a client written in language X reads this doc. Language X's JSON parser handles dups by
keeping the first key, so this client sees the color as blue.
A client in language Y reads this doc; Y's JSON parser keeps the last key, so this client
sees the color as green.
A client in language Z reads the doc but gets an invalid-JSON error because Z's parser is
strict and rejects duplicate keys. This client fails somehow. Hopefully it was checking errors
properly and doesn't just crash.

So here you have a situation where CouchDB allows a document into a database that two clients
can see in very different ways, while another client can't even read the document. That does
not seem like a happy place at _all_. Especially if you consider validation issues — what
if the database has a validation function that rejects green documents? The behavior now depends
on which of duplicate values the JS implementation inside CouchDB sees. (Is it still SpiderMonkey
or has it switched to V8? Do they have different behavior?) And a client with different rules
might see the document with the invalid color.

I am not a licensed security expert (though I've dated one), but to me this strongly smells
like a security hole in data validation. I'm pretty certain someone could find a way to build
an exploit out of this, inserting a doc that's allowed by the database's validator but which
reveals entirely different invalid contents to a client app with a different JSON parser.

View raw message