3

The OWASP insecure Deserialization threat is a well known one. My question is how to mitigate this threat when we are using parser libaries like Jackson etc on the java part?

Does validations using Hibernate validation or Java validation solve the issue? Or does any special or better techniques exists to mitigate this issue?

samshers
  • 1
  • 6
  • 37
  • 84
  • Take a look at [Which version of jackson-databind does not have remote execution vulnerability?](https://stackoverflow.com/questions/58754487/which-version-of-jackson-databind-does-not-have-remote-execution-vulnerability/58781813#58781813) – Michał Ziober Aug 03 '20 at 09:23

1 Answers1

3

First of all the whole deserialization thing is about deserialization of Java objects. It's not about XML demarshaling or reading JSON. There are other vulnerability classes to deal with these problems.

Imagine your code accepts a Java class as input (can be Bas64 encoded and provided over a REST endpoint). Why would someone do that? Well, if you would like to store the state remotely then you could serialize the Java class, send it and receive it back when it is needed. Makes no sense? Well, Jenkins did it anyway a while ago.

The real problem is not the deserialization, but the prevention of code execution during deserialization. How to prevent readObject() from being called? It will be called automatically. And preventing something that happens deep in Java code is a pain.

You can try and play with notsoserial or SerialKiller, but it will not make your code simpler and easier to read. The one thing that actually works is not using deserialization of untrusted objects anywhere in the code.

Marek Puchalski
  • 3,286
  • 2
  • 26
  • 35