Predictable Session-Cookie Secret Enabled Impersonation of 95 Accounts in Authorized Testing

Summary

Researchers found that a hard-coded cookie-signing secret and publicly exposed user IDs let them forge sessions for 95 of 241 tested accounts, including administrators, in an authorized staging assessment, bypassing application-level SSO and MFA.

Key points

The session cookie used a hard-coded, predictable HMAC-SHA256 signing secret identical to the cookie name; researchers recovered it by testing about 110 candidates.
The signed payload was a user's public database ID, exposed through API responses, rather than a random session identifier.
Researchers forged sessions without a victim's password, MFA challenge, or Entra ID access token.
Forged sessions worked for 95 of 241 tested user IDs, including administrator accounts; read/write access and an administrative state-changing action were demonstrated.
Testing was authorized and limited to the vendor's staging environment; no production systems were touched, and test records were restored.
Recommended fixes include rotating the secret, using random server-generated session IDs backed by server-side session state, invalidating existing sessions, and reviewing authentication logs.

Article Details

Attack Vectors: The application's session cookie used the user's publicly exposed database ID as its signed payload and a hard-coded signing secret identical to the cookie name, session_secret_example.
During authorized testing, Resecurity recovered the signing secret by testing approximately 110 candidate values offline against a captured legitimate cookie, then generated valid HMAC-SHA256 signatures for other user IDs.
User IDs were available in API responses, including /api/v1/auth/me, user list and detail endpoints, and user-directory endpoints.
The application accepted forged session cookies without requiring the victim's password, MFA challenge, or Entra ID access token. Testing demonstrated impersonation of employee and administrator accounts, including a state-changing administrative action.
The unauthenticated Swagger UI at /api-docs/ exposed the API route surface, according to the article.
Defensive Notes: Immediately rotate the session signing secret and invalidate existing sessions.
Replace public user IDs in cookies with random, unpredictable, server-generated session identifiers backed by server-side session state.
Generate a strong, unpredictable signing secret, store it securely, and use separate secrets for development, staging, and production.
If stateless tokens are required, use strong cryptographic keys, appropriate expiration and replay protections, and do not rely solely on a publicly exposed identifier for identity.
Review authentication logs for unusual session creation, account impersonation, administrative actions, and activity associated with unexpected user accounts.