Up-to-date guidelines for serialization usage [DATAREDIS-780]

[spring-projects-issues]

Mark Paluch opened DATAREDIS-780 and commented

Over the past few years, several incidents were related to using serialization-based message formats from untrusted data sources. We need to update our guidelines accordingly. While we generally recommend against Java serialization there are some recent efforts that allow for controlled exposure there, in particular the serialization filter that recently got introduced at JDK level (https://blogs.oracle.com/java-platform-group/entry/incoming_filter_serialization_data_a)

---

Affects: 2.1 M1 (Lovelace), 1.8.10 (Ingalls SR10), 2.0.5 (Kay SR5)

Backported to: 2.0.6 (Kay SR6), 1.8.11 (Ingalls SR11)

[spring-projects-issues]

Mark Paluch commented

We should reword our documentation to:

RedisCache and RedisTemplate are configured by default to use Java native serialization. Java native serialization is known for allowing remote code execution caused by payloads that exploit vulnerable libraries and classes injecting unverified bytecode. Manipulated input could lead to unwanted code execution on the server during the deserialization step. As a consequence, do not use serialization in untrusted environments. In general, we strongly recommend any other message format (e.g. JSON) instead.

If you are concerned about security vulnerabilities due to Java serialization, consider the general-purpose serialization filter mechanism at the core JVM level, originally developed for JDK 9 but backported to JDK 8, 7 and 6 in the meantime: https://blogs.oracle.com/java-platform-group/entry/incoming_filter_serialization_data_a http://openjdk.java.net/jeps/290