312-50V10 · Question #1
Insecure direct object reference is a type of vulnerability where the application does not verify if the user is authorized to access the internal object via its name or key. Suppose a malicious user
The correct answer is B. "GET/restricted/accounts/?name=Ned HTTP/1.1 Host: westbank.com". IDOR occurs when an attacker manipulates a parameter to directly reference another user's object without authorization checks. Choice B demonstrates this by substituting Ned's name into the URL to access his account.
Question
Insecure direct object reference is a type of vulnerability where the application does not verify if the user is authorized to access the internal object via its name or key. Suppose a malicious user Rob tries to get access to the account of a benign user Ned. Which of the following requests best illustrates an attempt to exploit an insecure direct object reference vulnerability?
Options
- A"GET/restricted/goldtransfer?to=Rob&from=1 or 1=1' HTTP/1.1Host: westbank.com"
- B"GET/restricted/accounts/?name=Ned HTTP/1.1 Host: westbank.com"
- C"GET/restricted/bank.getaccount(`Ned') HTTP/1.1 Host: westbank.com"
- D"GET/restricted/\r\n%00account%00Ned%00access HTTP/1.1 Host: westbank.com"
How the community answered
(29 responses)- A10% (3)
- B79% (23)
- C7% (2)
- D3% (1)
Why each option
IDOR occurs when an attacker manipulates a parameter to directly reference another user's object without authorization checks. Choice B demonstrates this by substituting Ned's name into the URL to access his account.
This request contains the classic SQL injection payload '1 or 1=1' appended to the 'from' parameter, making it an SQL injection attempt rather than an IDOR exploit.
This request uses the 'name=Ned' query parameter to directly reference Ned's account object by a user-supplied identifier. It illustrates IDOR because the application exposes an internal object (the account) via a guessable reference, and if it does not verify that Rob is authorized to access Ned's account, the attack succeeds. No injection payload is needed - simply changing the parameter value is enough to access another user's data.
The backtick syntax around 'Ned' resembles a stored procedure or command-substitution call, which is more indicative of a command injection or SQL stored-procedure attack, not a direct object reference exploit.
The null bytes (%00) and carriage-return sequence (\r\n) in the URL indicate a null-byte injection or HTTP response-splitting attack, not insecure direct object reference.
Concept tested: Insecure direct object reference (IDOR) exploitation
Source: https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/05-Authorization_Testing/04-Testing_for_Insecure_Direct_Object_References
Topics
Community Discussion
No community discussion yet for this question.