CEH Web Application and Injection Attacks Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  The application uses indirect object references (e.g., random tokens)

  Why it's wrong here

  Insecure Direct Object Reference (IDOR) attacks rely on an attacker's ability to guess or enumerate direct identifiers. When an application employs indirect object references, such as randomly generated tokens or GUIDs instead of sequential user IDs, it significantly increases the difficulty for an attacker to predict valid object identifiers. This abstraction prevents attackers from directly manipulating the reference to access unauthorized resources, thereby mitigating the IDOR vulnerability. Therefore, an application using indirect references would not be susceptible to a direct object reference attack.

• ✓

  The application exposes direct references to internal objects (e.g., user IDs in URLs)

  Why this is correct

  An attacker attempting an Insecure Direct Object Reference (IDOR) attack specifically targets applications that expose direct references to internal implementation objects. For instance, if a URL directly uses sequential database IDs like "/profile?id=123", an attacker can easily modify "id=123" to "id=124" to attempt access to another user's profile. This direct exposure provides the attacker with a clear pathway to manipulate object identifiers, which is a fundamental prerequisite for exploiting IDOR vulnerabilities.

• ✓

  The application fails to validate the user's authorization for the requested object

  Why this is correct

  While exposing direct object references is a prerequisite, an Insecure Direct Object Reference (IDOR) vulnerability is fully exploitable only when the application subsequently fails to perform proper authorization checks. After an attacker modifies a direct object reference (e.g., changing a user ID in a URL), the application must verify if the current authenticated user is authorized to access the requested object. Without this critical authorization validation, the application will grant access to objects the user is not entitled to see or modify, leading to a successful IDOR attack.

• ✗

  The application has a CSRF vulnerability

  Why it's wrong here

  A Cross-Site Request Forgery (CSRF) vulnerability allows an attacker to trick an authenticated user into unknowingly executing unwanted actions on a web application where they are currently logged in. This attack leverages the user's existing session and trust in the site, typically through malicious links or embedded images. CSRF focuses on forcing a user to perform an action, whereas Insecure Direct Object Reference (IDOR) involves an attacker directly accessing or manipulating objects by changing their identifiers. These are distinct attack vectors with different underlying mechanisms.

• ✗

  The application implements strong access controls on every object

  Why it's wrong here

  Strong access controls are a primary defense against Insecure Direct Object Reference (IDOR) vulnerabilities. If an application rigorously implements authorization checks for every object access, even when direct references are exposed, it will prevent unauthorized users from manipulating object identifiers to gain access. These controls ensure that before any operation is performed on an object, the system verifies that the requesting user has the necessary permissions, effectively blocking IDOR attempts by enforcing the principle of least privilege.

Go deeper

Related to this question