couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Second call for objections releasing 0.10
Date Mon, 21 Sep 2009 19:18:45 GMT
On Mon, Sep 21, 2009 at 2:12 PM, Curt Arnold <> wrote:
> Probably should not have ventured any opinion on a resolution since I had
> just scanned the thread and hadn't had any time to investigate it myself.
> However, it did seem to suggest a possible means of abuse and didn't seem to
> have a resolution at the moment.
> Doing a quick test with IE and FF, showed that:
> { withdrawl: 10000.00, withdrawl: 10.00 }
> appeared to be indistinguishable from:
> { withdrawl : 10.00 }
> Basically, it was as if you did:
> var doc = new Object();
> doc.withdrawl = 10000.0;
> doc.withdrawl = 10.0;
> and the first assignment got discarded.

I reckon that this would be the behavior of most parsers. I haven't
seen any that die on duplication, they generally just assign each key
to the language's object mapping type overwriting any previous value.
I think maybe I remember seeing Yajl have an option to call it an
error but I'd have to double check as I could just be making that up.

> As long as CouchDB is consistent with that interpretation, then there is not
> a problem as far as I can tell.
> If some level (like the query processor) saw both entries, then you might be
> able to exploit the discrepancy.

There's probably a possibility in confusing tools that don't expect to
see repeated JSON properties, but that won't get fixed by us rejecting
documents. We could just as well react like other tools and only
accept the final definition of the property, but who's to say that's
proper? As I remember it, there's no resolution for duplicate names
mentioned in the spec. And its not specified as an error condition.

My summary of this would be that its a fairly uncommon bug. I've seen
this one report in the two years or so I've been working with CouchDB.
To trigger the behavior you're pretty much required to write your own
JSON serializer as most standard implementations won't allow it. As to
a malicious attack, I'm not sure I see it. The only place people would
even notice it would be in the Erlang view code. And at that point I
would think that it'd just be a documentation issue when people are
doing security.

Even thinking forward to consider JSON serialization BIF's I doubt
that they would enforce unique keys by default as the preferred Erlang
representation uses a data structure without uniqueness constraints.
It'd be possible that there's an included option to check, but I don't
remember anything in the EEP about that.

Bottom line, I think we should just Relax on this for now. Unless
someone can illustrate even the remote possibility of an attack that
this would provide, or some sort of extreme incompatibility like
causing IE5.5 to segfault I don't consider it something that should be
worried about.

Also, once again to reiterate, this isn't *invalid* JSON. Just JSON
that people might not expect. And its only there if a client provided
it. CouchDB never generates duplicate properties to my knowledge.

Paul Davis

View raw message