4 ms·
Ugh, no. JSON is garbage, especially from a security standpoint. For security purposes you want an unambiguous format with a well-defined canonical representati
by patrec 5y ago
Ugh, no. JSON is garbage, especially from a security standpoint. For security purposes you want an unambiguous format with a well-defined canonical representation that's easy to parse. Not only is JSON none of these things, many people labor under the mistaken assumption that it's saner than it really is and even quite experienced people get bitten in the ass by that: https://github.com/endojs/endo/issues/115 https://github.com/endojs/endo/issues/115
Quoting http://seriot.ch/projects/parsing_json.html http://seriot.ch/projects/parsing_json.html:
In conclusion, JSON is not a data format you can rely on blindly. I've demonstrated this by showing that the standard definition is spread out over at least seven different documents (section 1), that the latest and most complete document, RFC-8259, is imprecise and contradictory (section 2), and by crafting test files that out of over 30 parsers, no two parsers parsed the same set of documents the same way (section 4).
Here's an example of an actually simple format where it's easy to define a canonical representation: https://en.wikipedia.org/wiki/Canonical_S-expressions https://en.wikipedia.org/wiki/Canonical_S-expressions; it was used for SPKI (https://theworld.com/~cme/html/spki.html https://theworld.com/~cme/html/spki.html) which sadly never went anywhere but is much more pleasant than the ASN.1/X.509/JWT etc mess that actually won.
- throwaway894345 5y agoJSON is very widely used, so if it’s properties were bad for security, we should expect different JSON-based attacks popping up every week, right? How often do we see these kinds of attacks?
- patrec 5y agoIt's not hard to find quite recent json parsing vulnerabilities, e.g. https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/modsecurity-dos-vulnerability-in-json-parsing-cve-2021-42717/ https://www.trustwave.com/en-us/resources/blogs/spiderlabs-b... A fun historical one was remote code execution due to a json parser bug in Google Chrome. Oops. If you try a simple search on mitre, you'll see some false positives, but also a bunch of actual vulnerabilities each year: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=json https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=json Here is a nice blog post walking through various JSON based exploits: https://bishopfox.com/blog/json-interoperability-vulnerabilities https://bishopfox.com/blog/json-interoperability-vulnerabili...
- throwaway894345 5y agoInteresting. I haven’t talk heard of any of those.
- bawolff 5y ago> Not only is JSON none of these things, many people labor under the mistaken assumption that it's saner than it really is and even quite experienced people get bitten in the ass by that: https://github.com/endojs/endo/issues/115 https://github.com/endojs/endo/issues/115 That link is not an issue with json, but with javascript (that js treats keys named __prototype__ special). Its one of the most famous js security bugs, and also applies to xml and whatever else if you dont implement the parser carefully.
- patrec 5y ago> That link is not an issue with json, but with javascript (that js treats keys named __prototype__ special). JSON is meant to be (and was widely advertised as) a Javascript subset, but isn't, but almost no one is aware of this. So of course it's also an issue with JSON. It's also not the only divergence that leads to security problems, in fact if you follow the first link in the comment you will see that this was posted in the context of trying to fix another misspecification in an attempt to actually make JSON a proper subset (which turned out to be impossible to completely accomplish, although at least the paragraph separator issue has been fixed in 2019). See here: https://v8.dev/features/subsume-json https://v8.dev/features/subsume-json