Not using hand-written shitty parsers, having a spec and validating it too.

Or day drinking and quitting your job, depending on the mood.

ASN.1 done right is pretty easy to secure, and much less error prone than pretty much any text format

Fuzz for low hanging fruits.

Analyze code: peer review, bounty, ...

Harden through invariant checks and logic checks.

Make your system/code anti fragile by detecting wrong encoding, reporting it (uh-huh, yeah, think that any code even reporting/logging is an attack surface, hint hint log4j) and treating future traffic from source of attacks as a way to train your defense.

Create a culture of security: simple architecture, design workshops, threat modeling, thinking about what someone with attacker mindset would do, value experience (coming defense source) AND involve newbies (they will try again what didn't work in the past, and sometime it works)

XDR perhaps? Less ambitious than ASN1. Used by many systems.

https://en.wikipedia.org/wiki/External_Data_Representation

Generally speaking, from a security standpoint, simpler is better. It of course depends on your requirements, but if you just need a structured data exchange format, JSON is an obvious choice. But again, it depends on what your requirements are.

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

Quoting 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; it was used for SPKI (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.

> 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

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.

> 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

JSON 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?

It's not hard to find quite recent json parsing vulnerabilities, e.g.

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

Here is a nice blog post walking through various JSON based exploits:

https://bishopfox.com/blog/json-interoperability-vulnerabili...

Interesting. I haven’t talk heard of any of those.

JSON is not a simple format. I don't feel confident enough to recommend anything in particular, but I believe one of the well-designed binary formats would be a much better choice.

I'll just leave this here.

https://news.ycombinator.com/item?id=28826600

https://seriot.ch/projects/parsing_json.html

IMO Json is more complex than the popular DER/BER encoding of ASN.1 and suffers from an ambiguous specification.

I'd rather use CBOR instead of JSON when doing anything outside the browser that doesn't need to be human editable

IMHO: CBOR is a worse encoding than msgpack, despite being a copy-paste clone of msgpack: Indefinite lengths, weird fp formats (decimal floats?), iirc CBOR also "improved" msgpack's int encoding by making it annoying to de- and encode, the whole tagging system is superfluous etc.

Just because something has an RFC number doesn't make it good.

Robust methods of parsing untrusted inputs.