On Mon, Sep 21, 2009 at 2:12 PM, Curt Arnold <[email protected]> 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. HTH, Paul Davis
