3 ms·

What do the security experts recommend?

by rixed 5y ago

emmelaich 5y ago
XDR perhaps? Less ambitious than ASN1. Used by many systems. https://en.wikipedia.org/wiki/External_Data_Representation https://en.wikipedia.org/wiki/External_Data_Representation
bawolff 5y ago
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.
- 5e92cb50239222b 5y ago
  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://news.ycombinator.com/item?id=28826600 https://seriot.ch/projects/parsing_json.html https://seriot.ch/projects/parsing_json.html
- CodesInChaos 5y ago
  IMO Json is more complex than the popular DER/BER encoding of ASN.1 and suffers from an ambiguous specification.
- pantalaimon 5y ago
  I'd rather use CBOR instead of JSON when doing anything outside the browser that doesn't need to be human editable
  - formerly_proven 5y ago
    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.
- 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 ago
    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?
    - patrec 5y ago
      It'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...
- deleted 5y ago
  [deleted]
philprx 5y ago
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)
p_l 5y ago
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
fulafel 5y ago
Robust methods of parsing untrusted inputs.

What do the security experts recommend?

by rixed 5y ago

What do the security experts recommend?

XDR perhaps? Less ambitious than ASN1. Used by many systems. https://en.wikipedia.org/wiki/External_Data_Representation https://en.wikipedia.org/wiki/External_Data_Representation

bawolff 5y ago

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.

5e92cb50239222b 5y ago
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://news.ycombinator.com/item?id=28826600 https://seriot.ch/projects/parsing_json.html https://seriot.ch/projects/parsing_json.html
CodesInChaos 5y ago
IMO Json is more complex than the popular DER/BER encoding of ASN.1 and suffers from an ambiguous specification.
pantalaimon 5y ago
I'd rather use CBOR instead of JSON when doing anything outside the browser that doesn't need to be human editable
- formerly_proven 5y ago
  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.
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 ago
  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?
  - patrec 5y ago
    It'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...
deleted 5y ago
[deleted]

philprx 5y ago

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)

p_l 5y ago

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

fulafel 5y ago

Robust methods of parsing untrusted inputs.