5 ms·
I don't get the section on JSON, which seems to assert that XML is more secure than JSON. It does this by linking to a Wikipedia page that includes the security
by hyperpape 9y ago
I don't get the section on JSON, which seems to assert that XML is more secure than JSON. It does this by linking to a Wikipedia page that includes the security consideration that you shouldn't call eval on JSON. True, but at least that's a tractable problem. Your linter can check for code that calls eval.
In contrast, there are plenty of XML attacks (DOS with billions of laughs, entity references), and parsing XML is a lot more complicated, which matters a great deal if you're using non-memory-safe libraries for parsing. Also, because XML is so general purpose, you get things like libraries allowing deserialization of arbitrary objects from XML, which is a security nightmare.
That last point isn't a clean win because sometimes the same library will handle JSON and XML, and so you have to audit the use carefully. However, if you're sure that your serialization libraries only use JSON, its simplicity means that it shouldn't have that kind of deserialization vulnerability.
P.S. If you want to rag on JSON, that's fine. It's not a great format. But "it's less secure than XML" is not the tack I'd take.
- hutzlibu 9y ago"If you want to rag on JSON, that's fine. It's not a great format" JSON is simple and powerfull. It's success justifies it, to call it a great format, I think. But I am curious, what whould be a great format, in your opinion?
- jaltekruse 9y agoA standard way to at least represent common data types, dates/times, integers/longs and fixed precision decimal would be nice. I know that the JSON format doesn't specify any limit or precision limitations on the size of numeric values, but almost all libraries assume they should be read as doubles. It is a real pain for people doing analysis on semi-structured JSON after apps have been deployed for a while and the data model has evolved over time.
- hyperpape 9y agoJSON gets the most important thing right: it's simpler than XML. I probably should have rephrased my comment. I literally mean that it's a decent format, but not a great one. One issue is that it's surprisingly poorly specified: http://seriot.ch/parsing_json.php http://seriot.ch/parsing_json.php. As a data-interchange format, it lacks first class dates/timestamps, the issues about specification are a pain when dealing with numbers (depending on language, you may not be able to use the full range of 64 bit ints), and has no builtin concept of schemas. That said, I'm not sure what I'd recommend above JSON, though you clearly wouldn't use it for really high performance servers. It's also used as a configuration language, where more issues surface. It doesn't accept trailing commas or comments (I can see the argument for requiring all keys to be quoted, but that's a pain to write as well). For configuration, I think I prefer TOML to JSON. Dhall looks cool, but I've never used it.
- hutzlibu 9y agoYes, your criticism is very valid and I agree to it - I still think JSON is a great (simple!) format, though. And I hope, that all the missing things like schemas can and will be added at some point, when there is a consensus on how ... And TOML and Dhall look interesting, but I like the block approach with brackets to data like JSON does it.
- Spivak 9y agoI think it's weird to criticize JSON the format for lacking these specific features. I think there is absolutely an argument to be made that its simplicity often means that it's not the right tool for the job. There are a lot of developers who are stuck on making JSON do horrible things and end up reinventing the wheel poorly because 'XML is gross' but I wouldn't say the right answer is to add these features to JSON.
- emodendroket 9y agoI really wish it had a format for dates.
- hutzlibu 9y agoI use just a "time" number for it (but I also do not have dates before 1970)
- emodendroket 9y agoWell the fact that you and the other guy offered different "standards" to use is kind of exactly my point.
- TheAceOfHearts 9y agoISO 8601 [0] defines the standard for data elements and interchange formats. It's widely supported on all major programming languages. The only issue is having to manually convert the string. [0] https://en.wikipedia.org/wiki/ISO_8601 https://en.wikipedia.org/wiki/ISO_8601
- emodendroket 9y agoIt's not defined as the standard date representation for JSON, nor is anything else, so every library does its own incompatible thing.