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
