312-50 Question 310
Single answer▪ Analyze Web ApplicationsDuring an authorized assessment of a customer portal, you intercept a request to /account/update and notice the application sends the following POST body: email=user@corp.com&role=user&userId=4821. After changing role=user to role=admin in your proxy and forwarding the request, the server responds with HTTP 200 and the page later shows administrative menu items for that account. The tester wants to classify the issue correctly before documenting impact and remediation. Which vulnerability best describes this finding?
- A
Mass assignment vulnerability due to unsafe binding of client-supplied parameters to server-side object properties
- B
Cross-site request forgery (CSRF) because the request changes account data through a POST action
- C
SQL injection because modifying a parameter changed the application's authorization state
- D
Insecure Direct Object Reference (IDOR) because the request contains a userId value
Show answer and explanation
Correct answer: A
Explanation
The most accurate classification is mass assignment: the application is accepting a sensitive field from the client and binding it directly to a server-side object without proper allowlisting or authorization checks. This leads to vertical privilege escalation because a normal user can assign themselves an administrative role simply by tampering with a parameter in transit. In a CEH-style web application analysis scenario, the candidate should distinguish between similar-looking flaws: CSRF concerns unauthorized request origination from a victim browser, SQL injection concerns query manipulation, and IDOR concerns unauthorized access to objects through identifiers. OWASP describes this issue under mass assignment and recommends defensive measures such as allowlisting bindable fields, rejecting sensitive properties from client input, and performing server-side authorization checks on any privilege-related change. Related best practices are also reflected in OWASP Top 10 guidance under Broken Access Control and secure coding recommendations for MVC/API frameworks.
- A. Correct.
Correct. This is a classic mass assignment issue, also called autobinding/object injection in some frameworks, where the server accepts client-controlled fields and maps them directly to sensitive model attributes such as role. The key indicator is that changing a hidden or expected parameter from role=user to role=admin results in privilege escalation without proper server-side allowlisting. OWASP guidance recommends binding only explicitly permitted fields and enforcing authorization checks on sensitive attributes.
- B. Incorrect.
Incorrect. CSRF is about forcing an authenticated user's browser to submit an unwanted request, typically because anti-CSRF protections are missing or weak. In this scenario, the tester directly modified a parameter in an intercepted request and the core issue is that the server trusted a client-supplied privilege field. A POST request that changes state is not, by itself, evidence of CSRF.
- C. Incorrect.
Incorrect. SQL injection involves influencing backend SQL queries through unsanitized input, often resulting in authentication bypass, data extraction, or database manipulation. Here, there is no indication of SQL syntax manipulation or database error behavior. The authorization state changed because the application accepted an unauthorized role value, not because a SQL query was injected.
- D. Incorrect.
Incorrect. IDOR occurs when an application exposes a reference to an internal object, such as userId=4821, and fails to enforce authorization on access to that object. Although the presence of userId could suggest an IDOR test path, the demonstrated exploit is privilege escalation by altering the role parameter. If changing userId allowed access to another user's record, that would support IDOR; that is not the primary issue shown here.