possible look at json edge cases

[pjfanning]

https://github.com/zio/zio-json#security has a good description of trying to fail early for malicious json inputs. I'm not sure where jackson-databind stands with problematic json as described in the link. I guess the aim would be to fail while building the JSON AST.

Apologies if jackson(-databind) already has support for these malicious formats.

[cowtowncoder]

This looks valuable, thank you @pjfanning!

For what it is worth, there have been improvements in many of these areas over past couple of years.
For example:

1. Handling of both HUGE and (a small number of) dangerous BigDecimal values has been improved to fail before causing likely resource exhaustion
2. Since beginning, Jackson has allowed feeding input as incremental (like InputStream) and NEVER require reading full content as String (note however that this does not mean that JSON String values within could not be problematic)
3. Handling of Deep Nesting works without DoS concerns at streaming level (JsonParser), and with Jackson 2.13 also with JsonNode (but there's on-going work, see below)
4. Use of HashMap directly was removed from streaming API -- JsonParser uses its own data structures that are not prone to specific attack (and there's no published attack against scheme that is used; theoretically there may well be potential for scheme of course). And JDK itself has improved in this area with later JDK 8 and above
5. Over time processing has been changed to try to reduce eager reading to avoid some of more obvious DoS vectors: meaning that content is only read when it is needed/requested.

In addition there is some on-going active work; for example:

• Wrt (3) above, there is Optimize UntypedObjectDeserializer wrt recursion [CVE-2020-36518] jackson-databind#2816 to try to allow essentially unlimited nesting for java.lang.Object too (as per above, JsonNode already does this)
• More generally, it'd be valuable to start limiting maximum content sizes directly at streaming level -- Add configurable processing limits for JSON parser (StreamReadConstraints) jackson-core#637 -- this follows work I did a few years ago with XML (Woodstox has a robust set of such limits).

In general I think that lists like above could help figure out some problematic aspects, but do require sort of incremental approach: there will always some potential concerns; and conversely there is no universal one fix to plug all holes.
We also get reports by Security Researchers occasionally outlining practical attacks.

Anyway: I think I will add above link to issue "core#637" as some more background.