CWE-579: J2EE Bad Practices: Non-serializable Object Stored in Session

What is J2EE Bad Practices: Non-serializable Object Stored in Session?

• Overview: J2EE Bad Practices: Non-serializable Object Stored in Session (CWE-579) refers to the issue where a Java application stores objects that are not serializable in an HttpSession. This poses a problem for applications running across multiple JVMs because it prevents the session from being replicated, which is essential for maintaining user session continuity across different JVMs for reliability and performance.

• Exploitation Methods:

• Attackers cannot directly exploit this vulnerability to execute malicious activities.
• Common attack patterns focus on exploiting the application's inability to handle session data correctly, potentially leading to service disruptions.

• Security Impact:

• Direct consequences include application crashes or loss of session data when a JVM fails and another tries to take over.
• Potential cascading effects include user dissatisfaction due to interrupted sessions and the need to re-login or re-enter data.
• Business impact involves reduced reliability and user confidence, potentially leading to a loss of revenue and reputation.

• Prevention Guidelines:

• Specific code-level fixes include ensuring all objects stored in the session implement the Serializable interface.
• Security best practices involve auditing session objects to confirm they are serializable and testing session replication across JVMs.
• Recommended tools and frameworks include using Java serialization libraries to validate object serializability and employing application servers with robust session management capabilities.

Corgea can automatically detect and fix J2EE Bad Practices: Non-serializable Object Stored in Session in your codebase. [Try Corgea free today](https://corgea.app).

Technical Details

Likelihood of Exploit: Not specified

Affected Languages: Java

Affected Technologies: Not specified

Vulnerable Code Example

// This code stores a non-serializable object in the HttpSession, which is a bad practice.
// If the session needs to be persisted (e.g., during server restarts or when distributed across multiple servers), 
// this will lead to issues because the object cannot be serialized and deserialized correctly.

import javax.servlet.http.HttpSession;

public class UserSessionManager {
    public void storeUserInSession(HttpSession session, User user) {
        session.setAttribute("user", user); // Non-serializable object stored in session
    }
}

class User {
    private String name;
    private String email;
    
    // Constructor, getters, and setters...
}

How to fix J2EE Bad Practices: Non-serializable Object Stored in Session?

To fix this issue, it is important to ensure that any object stored in the session implements the Serializable interface. This allows the object to be properly serialized and deserialized when the session is persisted across different nodes or server restarts.

Steps to fix:

1. Implement Serializable Interface: Modify the class of the object being stored in the session to implement the Serializable interface.
2. Mark Transient Fields: If there are fields in the class that should not be serialized (e.g., sensitive data or non-serializable fields), mark them as transient.
3. Ensure All Fields Are Serializable: Ensure all non-transient fields within the class are also serializable or are primitive data types.
4. Perform Testing: After making these changes, thoroughly test the application to ensure that objects in the session are properly serialized and deserialized.

Fixed Code Example

import javax.servlet.http.HttpSession;
import java.io.Serializable;

public class UserSessionManager {
    public void storeUserInSession(HttpSession session, User user) {
        session.setAttribute("user", user); // Now stores a serializable object in session
    }
}

class User implements Serializable { // Implements Serializable to allow session storage
    private static final long serialVersionUID = 1L;
    private String name;
    private String email;
    
    // Marking sensitive or non-serializable fields as transient
    private transient String password; // Example of a field that should not be serialized

    // Constructor, getters, and setters...
}

Explanation:

• Serializable Interface: The User class now implements Serializable, making it eligible for session storage.
• serialVersionUID: This is a unique identifier for the class version used during serialization and deserialization to ensure compatibility.
• Transient Keyword: Fields like password that should not be serialized are marked transient, preventing them from being included in the serialized form. This is crucial for sensitive information or fields that might not be serializable themselves.

By implementing these changes, the application ensures that storing objects in the session does not lead to issues when sessions are persisted or transferred.