5 ms·

> JSON is still the only secure by default one (if you ignore the two later updates, which made it How can a data format be insecure? > JSON is by far the eas

> JSON is still the only secure by default one (if you ignore the two later updates, which made it How can a data format be insecure? > JSON is by far the easiest to parse (small and secure, no references), It's relatively easy to parse (while not as easy as a sane well-specified version of CSV would be). But it also offers no structural integrity, which means that you need to augment the parsing code with terribly ugly validation code. (I don't really use JSON frequently, but the attempts at providing a principled validation framework on top of JSON that I've seen were... unsatisfying). > In every application, any dependency to XML should be minimized, contained and preferably eliminated. That's missing the point. It's not about JSON vs XML vs whatever. It's that application logic shouldn't be operating on transport data formats. And even if JSON has a simple representation as runtime data objects (in most scripting languages), that representation is pretty far from ideal compared to a representation tailored towards your specific application logic.

legulere 7y ago
> How can a data format be insecure? XML external entities allow for arbitrary file inclusion: https://en.wikipedia.org/wiki/XML_external_entity_attack https://en.wikipedia.org/wiki/XML_external_entity_attack You can make a badly configured XML parser allocate memory until it crashes: https://en.wikipedia.org/wiki/Billion_laughs_attack https://en.wikipedia.org/wiki/Billion_laughs_attack You cannot host user-generated xmls on a domain without making yourself vulnerable to cross site scripting attacks. Browsers will happily execute any javascript you include: https://stackoverflow.com/questions/384639/how-to-include-javascript-in-xml-document https://stackoverflow.com/questions/384639/how-to-include-ja...
__MatrixMan__ 7y ago
> How can a data format be insecure? If it tries to be too featureful, then it requires parsers to be very flexible. Malicious input can trick a too-flexible parser into doing things that the developer of whatever function called the parser probably didn't want to happen. For example, YAML: https://arp242.net/yaml-config.html https://arp242.net/yaml-config.html
- rurban 7y ago
  I have this overview: https://metacpan.org/pod/Cpanel::JSON::XS#SECURITY-CONSIDERATIONS 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) must be properly nested, it does not need this. From the 2nd RFC 7159 on it became insecure, and the 3rd RFC 8259 is merely a joke, as it didn't fix the known issues, only removed a harmless feature.
  - enbea 7y ago
    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 to require UTF-16 and UTF-32 support. ( unless you have some special requirements on encoding, in which case you can just disregard that part and convert it on both ends yourself ) The only "issue" with non-object values I see is the one mentioned in the above link where naively concatenating JSON might lead to errors when you send two consecutive numbers but that's going to rarely happen so your system can just reject top-level numbers if it doesn't expect them. And even then the simple solution is to just add whitespace around it.
    - rurban 7y ago
      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 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.
rurban 7y ago
> It's relatively easy to parse (while not as easy as a sane well-specified version of CSV would be). Wrong. CSV is horrible to parse with its string quoting rules. JSON accepts only utf8 and is not misleaded by \, nor ",". Done both, JSON is much simpler and can represent nested structures, arrays or maps. CSV importers are mostly broken, and should be left to Excel folks only. > It's that application logic shouldn't be operating on transport data formats Nobody is talking about application logic here but you. JSON is one of the best transport data formats, and this library makes it much easier to encode/decode from/to JSON and C++. We are not talking about javascript's hack to prefer JSON over full objects. Of course is an internal representation always better than an external, esp. such a simplified one. But for transports simple ones are preferred over complicated serialized ones, because then you can easily do MITM stack-overflows or abusing side effects on creating arbitrary objects.
- charliesome 7y ago
  CSV as a format doesn't really exist. CSV is a family of similar but not always compatible data formats each with their own special rules and edge cases. Note that the quote is talking about a well-specified CSV, not any CSV in general. A well-specified CSV would indeed be fairly easy to parse.
  - rusk 7y ago
    > CSV as a format doesn't really exist. RFC-4180
    - jstimpfle 7y ago
      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.
      - rusk 7y ago
        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 ...
taffer 7y ago
> And even if JSON has a simple representation as runtime data objects (in most scripting languages), that representation is pretty far from ideal compared to a representation tailored towards your specific application logic. Often you have control over the sending and receiving parts of an API and can design the transport format to fit your application logic. For example, I am currently using a GraphQL API and the data structures I get from this API are exactly what I need in my application.

legulere 7y ago

> How can a data format be insecure? XML external entities allow for arbitrary file inclusion: https://en.wikipedia.org/wiki/XML_external_entity_attack https://en.wikipedia.org/wiki/XML_external_entity_attack You can make a badly configured XML parser allocate memory until it crashes: https://en.wikipedia.org/wiki/Billion_laughs_attack https://en.wikipedia.org/wiki/Billion_laughs_attack You cannot host user-generated xmls on a domain without making yourself vulnerable to cross site scripting attacks. Browsers will happily execute any javascript you include: https://stackoverflow.com/questions/384639/how-to-include-javascript-in-xml-document https://stackoverflow.com/questions/384639/how-to-include-ja...

__MatrixMan__ 7y ago

> How can a data format be insecure? If it tries to be too featureful, then it requires parsers to be very flexible. Malicious input can trick a too-flexible parser into doing things that the developer of whatever function called the parser probably didn't want to happen. For example, YAML: https://arp242.net/yaml-config.html https://arp242.net/yaml-config.html

rurban 7y ago
I have this overview: https://metacpan.org/pod/Cpanel::JSON::XS#SECURITY-CONSIDERATIONS 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) must be properly nested, it does not need this. From the 2nd RFC 7159 on it became insecure, and the 3rd RFC 8259 is merely a joke, as it didn't fix the known issues, only removed a harmless feature.
- enbea 7y ago
  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 to require UTF-16 and UTF-32 support. ( unless you have some special requirements on encoding, in which case you can just disregard that part and convert it on both ends yourself ) The only "issue" with non-object values I see is the one mentioned in the above link where naively concatenating JSON might lead to errors when you send two consecutive numbers but that's going to rarely happen so your system can just reject top-level numbers if it doesn't expect them. And even then the simple solution is to just add whitespace around it.
  - rurban 7y ago
    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 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.

rurban 7y ago

> It's relatively easy to parse (while not as easy as a sane well-specified version of CSV would be). Wrong. CSV is horrible to parse with its string quoting rules. JSON accepts only utf8 and is not misleaded by \, nor ",". Done both, JSON is much simpler and can represent nested structures, arrays or maps. CSV importers are mostly broken, and should be left to Excel folks only. > It's that application logic shouldn't be operating on transport data formats Nobody is talking about application logic here but you. JSON is one of the best transport data formats, and this library makes it much easier to encode/decode from/to JSON and C++. We are not talking about javascript's hack to prefer JSON over full objects. Of course is an internal representation always better than an external, esp. such a simplified one. But for transports simple ones are preferred over complicated serialized ones, because then you can easily do MITM stack-overflows or abusing side effects on creating arbitrary objects.

charliesome 7y ago
CSV as a format doesn't really exist. CSV is a family of similar but not always compatible data formats each with their own special rules and edge cases. Note that the quote is talking about a well-specified CSV, not any CSV in general. A well-specified CSV would indeed be fairly easy to parse.
- rusk 7y ago
  > CSV as a format doesn't really exist. RFC-4180
  - jstimpfle 7y ago
    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.
    - rusk 7y ago
      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 ...

taffer 7y ago

> And even if JSON has a simple representation as runtime data objects (in most scripting languages), that representation is pretty far from ideal compared to a representation tailored towards your specific application logic. Often you have control over the sending and receiving parts of an API and can design the transport format to fit your application logic. For example, I am currently using a GraphQL API and the data structures I get from this API are exactly what I need in my application.