Hi Sai, Thank you very much for your careful review and for raising these important architectural considerations. I appreciate your insights and the thoughtfulness you bring to ensuring Apache Geode’s security.
I’d like to provide some context on why I took the dual-filter approach intentionally and how it aligns with established security practices. Comprehensive details along with the architectural diagram are available here: https://github.com/apache/geode/pull/7941#issuecomment-3617666432 Rationale for Separate Filters The two filters address fundamentally different trust boundaries and threat models: -HTTP/Session (SafeDeserializationFilter, 80 classes, always active): Protects against external attackers, session hijacking, and unsafe user input. -Cluster/Internal (validate-serializable-objects, 485 classes, optional): Protects internal replication, peer-to-peer communication, and cluster integrity. This separation reflects standard defense-in-depth architecture (Spring Security, AWS, Kubernetes, Hazelcast, Microsoft SDL). Each boundary requires independent policies; merging them could weaken security. Addressing Your Discussion Points -Extending existing infrastructure: Not ideal. Cluster filters protect internal data, while SafeDeserializationFilter targets the HTTP boundary. -Unified configuration: Unification would blur security boundaries; these configurations are intended to be managed by different roles. -Migration path: PR-7941 includes 80 common JDK classes in the allowlist. Existing session data works without migration. -Threat models: The filters address distinct threats, external HTTP attackers vs compromised cluster members with context-specific policies. PR-7941 introduces this new HTTP boundary layer to close the critical vulnerability while keeping cluster-level defenses optional. I hope this provides clarity on the architectural reasoning and why maintaining two separate filters is necessary. I value your guidance and would be happy to discuss this further if helpful. Best regards, Jinwoo Hwang (he/him/his) SAS® Research and Development http://JinwooHwang.com<http://jinwoohwang.com/> From: Sai Boorlagadda <[email protected]> Date: Thursday, December 4, 2025 at 12:18 PM To: [email protected] <[email protected]> Subject: PR 7941 - introduces session deserialization discussion EXTERNAL Hi Geode Community, I've been reviewing PR-7941 which addresses critical deserialization vulnerabilities in session management. The implementation is solid and well-engineered, but I'd like to step back and discuss the architectural approach before we proceed. ## Current PR Approach PR-7941 introduces SafeDeserializationFilter - a new, session-specific filtering system that operates independently of Geode's existing serialization infrastructure. ## Architectural Concern This creates a dual filtering system: 1. Existing Geode filters (GlobalSerialFilterConfiguration, ReflectiveFacadeStreamSerialFilter) for region data 2. New SafeDeserializationFilter for session attributes Since sessions are stored in Geode regions, session data potentially goes through BOTH filtering systems, creating: - Configuration complexity (two separate whitelist systems) - Operational burden (maintaining dual security policies) - User confusion (different config for sessions vs regions) - Potential security gaps (inconsistent policies) ## Discussion Points 1. Should we extend existing Geode serialization infrastructure instead? 2. How do we provide unified configuration for users? 3. What's the migration path for existing session deployments? 4. How do we handle the different threat models (web apps vs distributed cache)? ## Proposed Alternatives - Extend SerializableObjectConfig with session-specific options - Integrate with existing SanctionedSerializablesService - Provide session-specific sanctioned-serializables files - Unified validate-session-serializable-objects configuration I believe the security problem is real and urgent, but want to ensure we choose the right architectural approach for the long term. Thoughts? Best regards, Sai Boorlagadda
