Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON for Modern C++

github.com

Post reply on HN
Print view View original

121–125 of 125 posts

Re: JSON for Modern C++

#121

Post by jstimpfle »

rusk wrote: post #120
jstimpfle wrote: post #79

Earlier quoted context omitted.

That was created after how many years of CSV in the wild? Nobody disagrees here that parsing CSV in practice is a horrible minefield with lots of manual adjustments.

RFC-4180 is dated 2005 - so your statement that a standard "doesn't exist" has been out of date for 14 years. Yes of course there was no recognised standard before that. Just like before Greenwich Meantime there was no recognised standard for universal time coordination ...

It's not my statement, and also please let's not split hairs but look at the actual situation in practice. (Also, RFC-4180 sucks. It only codifies a subset of existing - bad - practice).

Re: JSON for Modern C++

#122

Post by rusk »

jstimpfle wrote: post #121
rusk wrote: post #120

Earlier quoted context omitted.

RFC-4180 is dated 2005 - so your statement that a standard "doesn't exist" has been out of date for 14 years. Yes of course there was no recognised standard before that. Just like before Greenwich Meantime there was no recognised standard for universal time coordination ...

It's not my statement, and also please let's not split hairs but look at the actual situation in practice. (Also, RFC-4180 sucks. It only codifies a subset of existing - bad - practice).

Apologies for the misattribution.

The situation in practice is that when people want a “standard” way to do CSV, there is in fact a standard they can use, that does cover most sensible things you’ll want to do with CSV, and addresses the most common corner cases (eg delimeter in field) in a fairly sensible way.

You are free yet to make whatever proprietary extensions or otherwise, at the risk of losing compatibility just as you are with any other standard.

Re: JSON for Modern C++

#123

Post by rurban »

enbea wrote: post #88
rurban wrote: post #65

Earlier quoted context omitted.

I have this overview: https://metacpan.org/pod/Cpanel::JSON::XS#SECURITY-CONSIDERA... which just misses details on stack-overflows on overlarge nesting levels, or denial of service attacks on overlarge strings, arrays or maps. Better formats which prepended sizes do have an advantage here, such as msgpack. But msgpack has no CRC or digest verification to detect missing or cut-off tails. JSON (its secure 1st RFC 4627)…

Could you elaborate on how are the 2nd and 3rd versions insecure and a joke? I've reread them and see no issues with either. Basically apart from clarifications and fluff about limits, security, and interoperability the only differences in the JSON spec itself are allowing any value at the top level and requiring UTF-8 for cross-system exchange. Since UTF-8 is the only sensible format for JSON it makes little sense t…

The 2nd version made it insecure, as scalars are not delimited anymore, and MITM or version mismatches can change the value.

schmorp wrote this:

> For example, imagine you have two banks communicating, and on one side, the JSON coder gets upgraded. Two messages, such as 10 and 1000 might then be confused to mean 101000, something that couldn't happen in the original JSON, because neither of these messages would be valid JSON.

> If one side accepts these messages, then an upgrade in the coder on either side could result in this becoming exploitable.

The 3rd version was a joke, because the outstanding problems were not addressed at all, and removing BOM support for the 4 other encodings is just a joke. First, you cannot remove a feature once you explicitly allowed it, esp. since it's a minor and an almost unused one.

And remember that http://seriot.ch/parsing_json.php was already published then, and the most egregious spec omissions had been known for years already. such as undefined order of keys, or undefined if duplicate keys are allowed. Allowing unsorted keys is also a minor security risk, as it exposes the internal hash order, which can lead to hash seed calculation.

Re: JSON for Modern C++

#124

Post by psyclobe »

Its a great library however 99% of its 'wow' moment can now be easily replicated with a few meta checks and can be adapted to basically any 3rd party json system.

Re: JSON for Modern C++

#125

Post by minitech »

josefx wrote: post #53
rurban wrote: post #48

Earlier quoted context omitted.

Then you should be enlightened: Of the myriads of existing transfer or serialization formats, * JSON is still the only secure by default one (if you ignore the two later updates, which made it insecure), * JSON is by far the easiest to parse (small and secure, no references), * is natively supported by Javascript. It has some minor design mistakes, and is not binary (such as msgpack, which is therefore faster), but s…

> JSON is still the only secure by default one (if you ignore the two later updates, which made it insecure), And enough people put it into eval that several companies started prepending while(1); to their JSON messages. Don't blindly trust user input no matter what format it comes in. > JSON is by far the easiest to parse (small and secure, no references), We all know its definition fits on a business card, which is…

> And enough people put it into eval that several companies started prepending while(1); to their JSON messages.

while(1); existed to work around a browser vulnerability where the same-origin policy could be bypassed by including cross-origin JSON as a . Nothing to do with eval.

Post reply on HN