3 ms·

There was a post here recently about how this sort of behaviour on duplicate keys has actually led to security issues (in the context of Go) [0] [0] https://ne

by anitil 1y ago

There was a post here recently about how this sort of behaviour on duplicate keys has actually led to security issues (in the context of Go) [0] [0] https://news.ycombinator.com/item?id=44308953 https://news.ycombinator.com/item?id=44308953

jmull 1y ago
The issue was triggered by using multiple parsers, with different behaviors. The change of behavior here would prevent the specific problem, but makes the general problem worse. This change creates a new code path that did not exist when all the app code was developed and tested, so there's a decent chance something bad can happen that it's not prepared for.
- anitil 1y ago
  The thing that I find surprising about this is that it seems so innocuous. Duplicate keys in an object? Meh just take the first or the last or something, no big deal, I'm sure whatever library I'm using will handle it
  - kazinator 1y ago
    RFC 8259 describes these possibilities, accurately quoted in the article: "Many implementations report the last name/value pair only. Other implementations report an error or fail to parse the object, and some implementations report all of the name/value pairs, including duplicates." Keeping the first key/value would be a poor idea since it is a behavior not mentioned in the RFC.
  - jmull 1y ago
    Just to point out, the problem in that issue isn’t really about JSON parsing. It’s about the layer whose job it is to verify/sanitize the input passing the unverified/unsanitized input through to the next layer. The idea that your JSON parser can catch this kind of error in the general case just doesn’t make sense. Changing the default behavior of the parser would catch this specific problem — by coincidence — but will also create new problems. They are as yet unknown, but we will find out (unless someone gains the sense to back off this bad idea before it makes it into production).

by anitil 1y ago

jmull 1y ago

The issue was triggered by using multiple parsers, with different behaviors. The change of behavior here would prevent the specific problem, but makes the general problem worse. This change creates a new code path that did not exist when all the app code was developed and tested, so there's a decent chance something bad can happen that it's not prepared for.

anitil 1y ago
The thing that I find surprising about this is that it seems so innocuous. Duplicate keys in an object? Meh just take the first or the last or something, no big deal, I'm sure whatever library I'm using will handle it
- kazinator 1y ago
  RFC 8259 describes these possibilities, accurately quoted in the article: "Many implementations report the last name/value pair only. Other implementations report an error or fail to parse the object, and some implementations report all of the name/value pairs, including duplicates." Keeping the first key/value would be a poor idea since it is a behavior not mentioned in the RFC.
- jmull 1y ago
  Just to point out, the problem in that issue isn’t really about JSON parsing. It’s about the layer whose job it is to verify/sanitize the input passing the unverified/unsanitized input through to the next layer. The idea that your JSON parser can catch this kind of error in the general case just doesn’t make sense. Changing the default behavior of the parser would catch this specific problem — by coincidence — but will also create new problems. They are as yet unknown, but we will find out (unless someone gains the sense to back off this bad idea before it makes it into production).