On Fri, Oct 5, 2018 at 9:28 AM Michael Rogers <[email protected]> wrote:
> Hi, > > I'd like to use Jackson to deserialize JSON from an untrusted source > into simple POJOs that can be used for further validation (checking that > values are within allowed ranges, etc). I've read a couple of blog posts > about deserialization attacks [1,2] and I'd like to ask if there are > some simple instructions I can follow to ensure my code isn't vulnerable > to these attacks, without having to keep up to date with the latest > gadget blacklists. > Ok. > As far as I can tell from @cowtowncoder's blog post, I should avoid > polymorphic type handling for any object or field whose declared type is > broad enough to cover a gadget. But the list of such types grows as new > gadgets are discovered. So if I understand right, the only way to be > safe against as-yet-undiscovered gadgets is to avoid polymorphic type > handling altogether. > Yes. > > That's absolutely fine - I haven't written the code yet, so I'm not > stuck with a legacy decision to use polymorphic type handling. So in > that case my question is how to use Jackson without polymorphic type > handling: > > a) to parse a JSON string into a JsonNode that I can walk to create a > POJO manually, or > b) to parse a JSON string into a POJO directly? > > On the other hand, if I've misunderstood and it's *not* necessary to > avoid polymorphic type handling altogether, then how can I use it safely > without keeping up to date with gadget blacklists? > I think you summarized well pertinent points. I would just mention one additional aspect: if you control the base type (and by definition subtypes I guess), you are likely to be safe. So if you "own" the type hierarchy, there is no attack vector. Another thing to consider is that attacks only work when using class name as the type id. Type name - based approach is unlikely to allow attacks, since one essentially has to register all subtypes: either via `@JsonSubTypes` or using Module to register them. And since you do not absolutely have to own subtype definitions (you may register any types, and via use of mix-in annotations [or reliance of type name defaulting to class name]), it does allow safe handling. But what can not be safely supported, without additional handler overrides, is support for open-ended type hierarchies (that is, for types you do not know about a priori). And for truly advanced use, you can technically write `TypeResolver`s (or `TypeIdResolver`s) that use some other heuristics to specify some kind of inclusion criteria (sort of custom allow-listing). I hope some of above helps: combination of open-ended flexibility and security are not easy to combine. -+ Tatu +- > > Thanks, > Michael > > [1] > > https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062 > > [2] > https://adamcaudill.com/2017/10/04/exploiting-jackson-rce-cve-2017-7525/ > > -- > You received this message because you are subscribed to the Google Groups > "jackson-user" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "jackson-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
