nerdexam
EC-Council

312-50V11 · 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…

The correct answer is B. "GET/restricted/accounts/?name=Ned HTTP/1.1 Host: westbank.com". Insecure Direct Object Reference (IDOR) occurs when an attacker manipulates a parameter that directly references an internal object to access data belonging to another user. Choice B demonstrates this by substituting another user's name directly in the query parameter.

Hacking Web Applications

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

(55 responses)
  • A
    7% (4)
  • B
    80% (44)
  • C
    2% (1)
  • D
    11% (6)

Why each option

Insecure Direct Object Reference (IDOR) occurs when an attacker manipulates a parameter that directly references an internal object to access data belonging to another user. Choice B demonstrates this by substituting another user's name directly in the query parameter.

A"GET/restricted/goldtransfer?to=Rob&from=1 or 1=1' HTTP/1.1Host: westbank.com"

This request contains '1 or 1=1' in the query string, which is a SQL injection payload, not an IDOR exploit.

B"GET/restricted/accounts/?name=Ned HTTP/1.1 Host: westbank.com"Correct

This request directly references the internal account object of user 'Ned' via the 'name' query parameter without any authorization check being enforced. Rob, as an authenticated but unauthorized user, is exploiting the application's failure to verify that the requesting user has permission to access the object identified by that parameter value. This is the textbook definition of IDOR - direct reference to an object by a predictable identifier with no access control validation.

C"GET/restricted/bank.getaccount(`Ned') HTTP/1.1 Host: westbank.com"

This request uses backtick syntax resembling a stored procedure or function call, which is more consistent with a SQL injection or command injection attempt rather than IDOR.

D"GET/restricted/\r\n\%00account%00Ned%00access HTTP/1.1 Host: westbank.com"

This request contains null bytes (%00) and URL-encoded characters consistent with a null byte injection or path traversal attack, not an IDOR exploit.

Concept tested: Insecure Direct Object Reference (IDOR) attack identification

Source: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/05-Authorization_Testing/04-Testing_for_Insecure_Direct_Object_References

Topics

#IDOR#web authorization#object reference#HTTP requests

Community Discussion

No community discussion yet for this question.

Full 312-50V11 Practice