Vulnerability Name: IDOR to Modify Another User’s Details with the Help of Session ID

What is IDOR?
A particular kind of access control vulnerability known as IDOR occurs when an application directly accesses objects using input provided by the user.
What is the impact of IDOR?
Due to inadequate authorization restrictions, an attacker can change private user information, including name, full name, contact information, bio, and country.
Mitigation:
- Do Not Trust Session ID from User Input
- Session IDs from request parameters (such as GET/POST) should never be accepted by server-side code.
- Session IDs from secure, HTTPOnly cookies should always be used.
- Session Binding to User Identity
- Session IDs should only be linked to the server’s authenticated user.
- Verify that the session belongs to the person who is presently logged in, even if someone sends you a different session ID.
- Authorization Check
- Verify that the person carrying out the action is the session owner at all times, even if the session ID is passed.
- Use Secure Cookies for Session IDs
- Mark cookies as:
- HttpOnly (so JS can’t access it)
- Secure (sent only over HTTPS)
- SameSite=Strict (to prevent CSRF)
- Regenerate Session ID on Login and Logout
- Minimizes the likelihood of session hijacking and stops session fixation.
Supporting Material/References:
- https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html
- https://book.hacktricks.xyz/pentesting-web/idor
POC
Step 1
- Click save changes and intercept a request.
Step 2
- Send to the repeater.
Step 3
- Launch a secret browser session, enter a separate username, and review the profile information for the second individual.
Step 4
- Send to the repeater
Step 5
- See the response status code 200 after changing the second request’s session ID to match the first request’s session ID.
Step 6
- When you reload the page, user information is automatically updated.
Read More
A Relief to the Bank Customers: Only a Specific Amount Would be Frozen