This builds an NotSoSerial jar file in target/notsoserial-1.0-SNAPSHOT.jar
Copy this as notsoserial.jar to your application, and add the following parameters to your Java startup script:

1

-javaagent:notsoserial.jar

PLEASE NOTE: In this mode, NotSoSerial only does blocks a few known vulnerabilities. It does not fix the problem with deserialization attacks. It only knowns about some well known classes for which it rejects deserialization. See below how you can whitelist or completely reject any objects to be deserialized.

Whitelisting mode
As always, it would be better if we could accept only classes we explicitly want to allow for deserialization. Rejecting based on a whitelist is better security than rejecting based on a blacklist.
To help build a whitelist file with legitimately serializable classes, a ‘dryrun’ option has been added. Together with an empty white list, this will create a list of classes which your application actually deserializes.

Where ’empty.txt’ is an empty file and ‘is-deserialized.txt’ is a file where the names of your actually deserialized classes will be written to.
After you are confident that all deserializable classes in your application have been recorded, you may restart your app, now reusing the recorded-as-serialized file as the whitelist:

1

-javaagent:notsoserial.jar-Dnotsoserial.whitelist=is-deserialized.txt

Rejecting deserialization entirely
Just use an empty whitelist. Preliminary testing with a non-trivial Java application (which does not intentionally use RMI or other serialization) seems to indicate that this might work just fine. Looks like the JDK might not need serialization for any of its internal operations.

Tracing deserialization
You might be interested not just in which classes your application deserialize, but also where in your code deserialization happens.
This can be enabled by using the ‘trace’ option, like the following: