A Modern Fairy Tale: Java Serialization
summary
Java serialization still moves object graphs easily but its self‑defining format lets attackers alter field types, bypass constructors and trigger static initializers — constructors are not called — so deserialization can execute unexpected code. Researchers count about 24 CVEs, exploit builders like ysoserial generate payloads and scanners such as Shodan locate vulnerable services. Known defenses include Java 9/JDK filters, custom ObjectInputStream validation, readObject checks, modularity and avoiding serialization, but gadget chains still enable remote code execution if unsafe classes remain on the classpath.
AI-written summary · about
chapters (10)
- 0:00Start
- 1:10Jvm Developer
- 2:59Why Do We Need Java Serialization At All
- 7:25Byte Stream
- 13:04Why Self-Defining Data Stream Dangerous
- 29:11Class Filtering
- 29:23Serialization Filter
- 31:14Modularity
- 37:30Gadget Chains
- 43:15Google Hacking Database
related talks
41mJava Serialisation: A Modern Fairytale
37mDeserialization in Java - is there still anything to fear?
41mHigh-Secure Java Serialization
53mWhy We Hate Java Serialization And What We're Doing About It
35mDangerous Serialization
40m[In]secure Deserialization, And How [Not] To Do It
34mDeserialization: what, how and why [not]
46mThe Anatomy of Java Vulnerabilities