28Hus opened a new pull request, #1565: URL: https://github.com/apache/dubbo-admin/pull/1565
## Summary This pull request addresses [Issue #1557](https://github.com/apache/dubbo-admin/issues/1557). Dubbo Admin uses a client-side signed session cookie for authentication. The signing key must therefore be deployment-specific and unpredictable. The current implementation still falls back to the publicly known value `secret` when no `sessionSecret` is configured. This leaves the default password-authentication path vulnerable to forged session cookies. ## Root Cause The OAuth/OIDC work in [PR #1542](https://github.com/apache/dubbo-admin/pull/1542) introduced the `sessionSecret` configuration field and changed the cookie store to use it. However, the same change also retained a legacy fallback: ```go const DefaultSessionSecret = "secret" ``` When the configuration does not contain a session secret, validation restores this public value. The minimum-length check is applied only to release deployments with external providers, so a password-only deployment can still start with the known signing key. As a result, adding a configuration field alone does not remediate the original issue. The insecure fallback remains reachable in the default authentication path. ## Changes This pull request: - removes the hard-coded default session secret; - requires a deployment-specific session secret; - rejects missing or shorter-than-32-byte secrets during startup; - supports `DUBBO_ADMIN_SESSION_SECRET` for Kubernetes and secret-manager based deployments; - updates the local and OAuth/OIDC configuration examples; - updates the Kubernetes deployment example to read the secret from a Kubernetes Secret; - keeps the session secret masked in displayed configuration and startup logs; - adds regression tests for password authentication, missing secrets, short secrets, environment injection, and secret sanitization. ## Security Behavior After this change: - a deployment without a configured session secret fails closed during startup; - the historical public value `secret` is rejected because it is too short; - a valid session cookie remains usable across restarts when the same configured secret is retained; - changing the configured secret invalidates existing session cookies, which provides a straightforward key-rotation mechanism. ## Usability and Future Improvements The current change intentionally prioritizes a secure default over zero-configuration startup. Generating a new secret only in process memory would make sessions invalid after every restart and would cause authentication failures between replicas using different keys. To improve usability in a future change, Dubbo Admin could provide an initialization command that generates a cryptographically secure secret once and persists it to a protected configuration file or external secret store. This would preserve stable sessions while keeping runtime startup fail-closed. Such an initialization flow should remain separate from the runtime fallback logic. ## Scope This pull request focuses on removing the predictable session signing key and preserving the existing signed-cookie session design. It does not redesign the application around a server-side session store or add session revocation. Those would be separate architectural changes. ## Testing The following checks pass locally: ```text go test ./... go vet ./... YAML configuration parsing Frontend production build ``` Fixes #1557 This work is part of my ongoing research, and I am very pleased to make a small contribution to improving the security of Apache Dubbo Admin. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
