ABSTRACT

Storing a non-serializable object as an HttpSession attribute can damage application reliability.

EXPLANATION

A J2EE application can make use of multiple JVMs in order to improve application reliability and performance. In order to make the multiple JVMs appear as a single application to the end user, the J2EE container can replicate an HttpSession object across multiple JVMs so that if one JVM becomes unavailable another can step in and take its place without disrupting the flow of the application.

In order for session replication to work, the values the application stores as attributes in the session must implement the Serializable interface.

Example 1: The following class adds itself to the session, but because it is not serializable, the session can no longer be replicated.


public class DataGlob {
String globName;
String globValue;

public void addToSession(HttpSession session) {
session.setAttribute("glob", this);
}
}

REFERENCES

[1] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A3 Broken Authentication and Session Management

[2] Standards Mapping - OWASP Top 10 2010 - (OWASP 2010) A3 Broken Authentication and Session Management

[3] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A7 Broken Authentication and Session Management

[4] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 579

[5] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.3

[6] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.5.7

[7] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.8

[8] The Java Servlet Specification Sun Microsystems

[9] The java.io.Serializable Interface Sun Microsystems