Allow serialise/deserialise only specific classes - whitelisting

[lukaszlenart]

As discussed in #1296 it would be good to allow define a whitelist with allowed classes that can be serialised/deserialised. This gives more control to the users and allows avoid any possible RCE attacks.

[cowtowncoder]

I suspect that a simple "provide a white-list of all classes" approach is impractical for most users: there are plenty of types already in JDK. But perhaps ability to specify a class/class-name validator (serialization / deserialization) validation, similar to:

FasterXML/jackson3-dev#21

would make sense?
In fact, perhaps that issue could be generalized to apply to all cases, not just polymorphic handling.
Come to think of this it seems unlikely that applying it for all values, even with explicit types defined (as property type or annotation) or passed (as target type argument), would cause problems.

EDIT: implemented as #2195, included in 2.10.0.

[lukaszlenart]

I think any of these will work, giving users an ability to control if a given class can be serialised/deserialised allows to build a whitelist anyway :)

[cowtowncoder]

True. And one more thought I had: if the check is only made when a new "POJO" (de)serializer is needed, it would not even apply to "standard" types, for which (de)serializer is already found.
This would mean, for example, that Enums are fine, arrays (element handlers are separate), numbers and so on. The only (?) possible concern would be tag types like Iterator.

So whatever validator was used could perhaps have couple of different methods, called at different points. Maybe some of these:

1. Class name (String) to Class lookup: could even block this just in case a security flaw only required loading of the class
2. Use of Class for polymorphic case (could block or change)
3. Actual use for serializer/deserializer access (before any lookups) -- applies to each and every type
4. Use for "POJO" (aka bean) (de)serializer: only applicable if no standard impl (enum, array, Map, Collection, reference; well-known JDK types; 3rd party types via modules) found

For security purposes, (4) probably really covers most if not all cases. And then user would only need to whitelist actual POJOs, and even those could be annotation based (i.e. user or 3rd party lib/framework defines tag annotation(s) to use, validator can look for that).

[lukaszlenart]

nice 💯

[artem-smotrakov]

@cowtowncoder If I understand correctly this issue (implementing whitelisting) is targeted only to 3.x, and the implementation of the whitelist depends on #2195. I have two questions:

1. Is there any plan to backport it to 2.x? I think it would be good to have whitelisting in 2.x as well.
2. Do you need any help with this issue, or Add abstraction PolymorphicTypeValidator, for limiting subtypes allowed by default typing, @JsonTypeInfo #2195? I can offer some help.

[cowtowncoder]

Implementation of #2195 is targeted for 2.10; I originally was thinking 3.x but I think it can't really wait that far.

I appreciate your offer to help, but unfortunately limit I have is time, not idea of how to implement this. So I don't think this is something that I can effectively parallelize until I get something working.
However, as soon as I have some pieces scoped I could definitely use help in validating my design and feedback like improvement suggestions.

[cowtowncoder]

@lukaszlenart @artem-smotrakov just a quick note: finally implemented most of #2195 so looking for feedback soon. I am reasonably content at design but hoping others to poke holes in it.

[lukaszlenart]

Nice, thanks a lot @cowtowncoder :) Is this already included in a released version?

[cowtowncoder]

@lukaszlenart No, it's still work-in-progress. It will be in 2.10.0; being API addition won't be backported.
But hoping to get the first pre-release (2.10.0.pr1) out within May 2019.

[lukaszlenart]

Great!

[bmaxwell]

Is there any ETA on this? It looks like there is going to be a continuous stream of CVEs to blacklist classes. The codehaus jackson added a whitelist which protects against any new classes from needing to be blacklisted and also lets the applications know and allow the classes to be deserialized.

[cowtowncoder]

@bmaxwell This was implemented via #2195 included in 2.10.0 (which was released 1 week ago) so closing this as dup. Overview of new features, including this one at

https://medium.com/@cowtowncoder/jackson-2-10-features-cd880674d8a2

but I hope to find time to blog about Safe Default Typing feature in bit more detail.