added whitelist for bean deserialization#5
Conversation
|
I appreciate your suggestion, but I a, not interested in this approach: nothing in Jackson is or should be configured using system properties (I consider them an anti-pattern). There are other existing patches that backport blacklist approach from Jackson 2.x which has to suffice; especially as security concern only affects cases where user explicitly enables either default typing, or specific polymorphic handling for a property using |
|
Hi @cowtowncoder , |
|
@NicoleG25 What have you done so far to find the answer? I do not remember CVE ids by hand, so please link information you have. Also note that this repo is for Jackson 1.x, last release for which was in 2013, no new releases planned. So if CVE is for Jackson 1.x, filed in 2019, that would not have been nor will be addressed. |
Jackson 1 is prone to deserialization attacks as discussed by Moritz Bechler in his MarshalSec research. This patch disables the dangerous features of Jackson 1 but allows a user to supply a whitelist of packages allowed to be unmarshalled.
If an unexpected class is attempted to be unmarshalled a JsonMappingException is throw similar to what has been implemented in Jackson 2. A user on receiving this exception can re-run their application with a System Property "jackson.deserialization.whitelist.packages" which adds the fully qualified class name or package name of the class they would expect to be deserialized.