312-50 Question 309
Single answer▪ Analyze Web ApplicationsDuring an authorized web application assessment, you intercept a POST request to /account/update in Burp Suite. The request updates the logged-in user's profile using a hidden parameter named userId. When you change userId from your own value to another sequential number, the server returns HTTP 200 and updates that other user's profile data. There is no anti-CSRF issue involved, and you are already authenticated as a low-privileged user. Which vulnerability best explains this behavior?
- A
Stored cross-site scripting (XSS), because user input is later rendered in another user's browser
- B
Insecure Direct Object Reference (IDOR), because the application uses a user-supplied object identifier without enforcing proper authorization
- C
SQL injection, because modifying a numeric parameter changes which database row is updated
- D
Session fixation, because the application accepts a user-controlled identifier during an authenticated workflow
Show answer and explanation
Correct answer: B
Explanation
The best answer is Insecure Direct Object Reference (IDOR), commonly categorized under Broken Access Control. The key evidence is that a low-privileged authenticated user can modify a direct reference to another user's object (userId) and the server processes the request successfully. Proper server-side authorization should validate that the authenticated user is permitted to update only their own profile, regardless of any client-side hidden fields. Hidden parameters do not provide security because they can be modified easily with proxy tools such as Burp Suite. This aligns with OWASP guidance on Broken Access Control and IDOR patterns, where applications expose internal identifiers and fail to enforce object-level authorization checks on the server.
- A. Incorrect.
Incorrect. Stored XSS involves injecting malicious script that is later served to other users and executed in their browsers. In this scenario, the issue is unauthorized modification of another user's record by tampering with a direct object reference, not script execution in the client.
- B. Correct.
Correct. This is a classic IDOR/Broken Access Control scenario: the application trusts a client-supplied identifier such as userId and performs the requested action without verifying that the authenticated user is authorized to access or modify that specific object. Changing a sequential identifier and successfully affecting another user's data is a common real-world indicator.
- C. Incorrect.
Incorrect. Although the parameter affects which record is updated, nothing in the scenario indicates that SQL syntax can be injected or that the backend query is unsafely constructed. Simply changing a numeric identifier to another valid value is more consistent with missing authorization checks than SQL injection.
- D. Incorrect.
Incorrect. Session fixation occurs when an attacker sets or forces a known session identifier that the victim later authenticates with, allowing the attacker to reuse that session. Here, the manipulated value is a profile object identifier (userId), not a session token, so the issue is not session fixation.