Session Fixation

Critical Session Fixation Leading to Full Account Takeover (ATO) Due to Missing Session Regeneration on Authentication at api.cleeng.com

Summary

The application suffers from a critical session management vulnerability where the backend reuses an existing PHPSESSID across authentication state changes.

The server neither destroys the existing session during logout nor generates a fresh session identifier after a successful login. Instead, it associates the already-existing session with the authenticated user.

I successfully validated this issue through a complete end-to-end proof of concept demonstrating full Account Takeover (ATO), proving the impact is practical rather than theoretical.

Vulnerable Component Host: api.cleeng.com Affected Cookie: PHPSESSID Root Cause

The application violates secure session management best practices by failing to regenerate the session identifier after authentication.

Specifically:

The same PHPSESSID remains unchanged before login, after login, after logout, and after logging in again. The backend binds authentication to an existing session instead of issuing a brand-new session. Logout does not invalidate the current session identifier.

This behavior enables Session Fixation attacks because an attacker-controlled session can later become an authenticated session.

Steps to Reproduce

1. Obtain an unauthenticated session

Visit the application and capture the assigned session cookie.

Example:

PHPSESSID=054emp1e23ovfiial3gd1lrk2f 2. Login

Authenticate using a legitimate account.

3. Observe the cookie

After login, inspect the cookies.

Result

The session identifier remains exactly the same.

Before login

054emp1e23ovfiial3gd1lrk2f

After login

054emp1e23ovfiial3gd1lrk2f

No session rotation occurs.

4. Logout

Logout from the account.

5. Login again

Authenticate once more.

6. Observe the cookie again

The same session identifier is still reused.

054emp1e23ovfiial3gd1lrk2f

This confirms that:

logout does not invalidate the session login does not regenerate a new session identifier Proof of Concept (Validated ATO)

The following attack was successfully demonstrated.

Step 1 — Session Harvesting

The attacker visits the application and captures an unauthenticated session cookie.

Example:

PHPSESSID=054emp1e23ovfiial3gd1lrk2f Step 2 — Session Fixation

The attacker causes the victim's browser to use this exact session identifier.

Step 3 — Victim Login

The victim logs into their legitimate account.

Step 4 — Authentication Binding

Instead of issuing a new session, the backend binds the authenticated account to the already existing attacker-controlled session.

The cookie remains:

PHPSESSID=054emp1e23ovfiial3gd1lrk2f Step 5 — Account Takeover

Using the same session cookie from another browser, the attacker requests authenticated endpoints such as:

/webapi/dashboard/broadcaster/profile

The server returns the victim's authenticated data.

The attacker gains full access without knowing the victim's credentials.

The attached PoC video demonstrates two separate browser sessions sharing the same session identifier and successfully accessing the victim's authenticated account.

Realistic Exploitation Scenarios

This attack is not limited to local access.

An attacker can realistically fix a session identifier through:

Cross-Subdomain Cookie Injection

If any subdomain under .cleeng.com contains a cookie injection vector (such as XSS, HTML Injection, Open Redirect with cookie injection, or similar client-side issues), the attacker can pre-set the session cookie for:

Domain=.cleeng.com

allowing the victim to authenticate using an attacker-controlled session.

Shared Environments Internet cafés Corporate workstations Shared kiosks Public terminals

where the same browser session may later be used by another user.

Security Impact

This vulnerability results in a complete compromise of authentication integrity.

An attacker can obtain:

Full Account Takeover Unauthorized authenticated session access Read/write access to user data Access to broadcaster dashboards Billing and financial configuration exposure Profile modification Account settings manipulation Privacy violation

Depending on the account type, this may also impact tenant management and administrative functionality.

Root Cause Analysis

The backend fails to perform proper session lifecycle management during authentication state changes.

Specifically:

Existing sessions are reused. Logout does not invalidate the current session. Login does not regenerate a new session identifier. Authentication is attached to an already existing session instead of a freshly created one. Remediation

Immediately after every successful authentication:

Destroy the existing server-side session. Generate a brand-new session identifier. Return the new identifier via the Set-Cookie header. Ensure old session identifiers cannot be reused.

For PHP applications, this typically involves:

session_regenerate_id(true);

Additionally:

Execute session_destroy() during logout. Remove any server-side mapping to previous session identifiers. Invalidate old sessions before creating new authenticated sessions. Ensure authentication state changes always trigger session rotation.