23 Чер, 2025

IDOR in the “Close session” functionality

Background — When Sessions Leak into Each Other

The internal session management portal allowed users to see active logins (e.g., from different devices) and close individual sessions manually. However, when closing one’s session, the request used a predictable identifier. This detail turned an innocuous feature into a potential mechanism for forcing other users to log out: anyone who had an active session could spoof the ID and close someone else’s session.

Discovery — From Self Logout to Session Hijack

1. Log in as a regular user.

2. Go to the Session

3. Management section.
Select the active session and click “End”.

4. Intercept the outgoing request in a proxy (e.g. Burp Repeater).

5. Pay attention to the body of the request:

				
					POST /api/session/close
Content-Type: application/json
{
  "session_id": 100243
}

				
			

6. Replace session_id with another ID (for example, 100244).

7. Send the request – the other user’s session is closed without errors.

8. The server returns 200 OK without checking if the session belongs to the request initiator.

Technical Root Cause — IDOR Without Ownership Validation

The server trusts the passed session_id and does not check if it belongs to the current user. There is no formal binding of the session to the user at the authorization level. This is a textbook example of Insecure Direct Object Reference (IDOR):

IDs are easily guessed (autoincrement).

• There is no permission check for the object.

The same endpoint serves both regular users and administrators.

Real-World Risks — What Attackers Could Do

Forced logout of any users (including administrators)

Disruption of business processes (e.g. sudden logout during an important operation)

Eliminating competitors in the online environment (games, bidding, chat sessions, etc.)

Use as a stage of a security mitigation attack (forced re-auth → social engineering)

Broader Lessons — Session Logic Needs Access Controls

– “Closing a session is a secure operation.” – But only for your own session.
– “If the user is authorized, then you can.” – Authorization ≠ authorization to an object.
– “It’s just a POST with an ID.” – IDOR doesn’t depend on method; it depends on owner validation.

Recommendations — How to Do It Right

✅ Binding objects to a user
The server must compare session.user_id with request.user_id before performing an operation.

✅ Switching to server-side IDs
Use UUIDs or internal tokens not available to the client.

✅ Centralized authorization
Implement an object access verification layer outside the business logic (e.g., policies/middleware).

✅ Audit all ID-accepting endpoints
Conduct vulnerability scans on all APIs that accept IDs in the body, URL, or query parameters.

✅ Logging of suspicious transactions
User_id → session_id mismatch should be logged and trigger an alert.

Інші Послуги

Готові до безпеки?

зв'язатися з нами