CISSP Software Development Security 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.

• ✗

  An attacker intercepts session cookies to impersonate a user

  Why it's wrong here

  This scenario describes session hijacking, where an attacker gains unauthorized control over a user's active session by stealing or predicting their session identifier, typically stored in a cookie. The attacker then uses this stolen session ID to bypass authentication and impersonate the legitimate user. This differs from an Insecure Direct Object Reference (IDOR) because it focuses on compromising the session itself rather than manipulating a direct reference to an application object.

• ✗

  An attacker uses a SQL injection to retrieve data from the database

  Why it's wrong here

  This describes a SQL injection vulnerability, which occurs when an attacker inserts malicious SQL code into input fields, causing the application's database to execute unintended commands. This allows the attacker to bypass security measures, retrieve sensitive data, or even modify database content directly. SQL injection is distinct from an Insecure Direct Object Reference (IDOR) as it targets the database query logic itself, rather than exploiting inadequate authorization checks on application-level object identifiers.

• ✗

  An attacker submits a cross-site request forgery (CSRF) token to perform actions

  Why it's wrong here

  This describes a Cross-Site Request Forgery (CSRF) attack, where an attacker crafts a malicious request that an authenticated user unknowingly executes, often by embedding it in a third-party site. The victim's browser then sends this forged request to the legitimate application, leveraging the user's active session. While CSRF tokens are typically a defense against such attacks, the core vulnerability lies in the application's trust in requests originating from an authenticated user's browser, rather than the direct manipulation of object identifiers as seen in IDOR.

• ✓

  An attacker changes the user ID parameter in a URL to view another user's profile

  Why this is correct

  This is a classic example of an Insecure Direct Object Reference (IDOR). The application directly exposes a reference to an internal implementation object, such as a user ID in a URL parameter, without adequately verifying the user's authorization to access that specific object. By simply modifying the user ID parameter, the attacker can bypass access controls and retrieve or manipulate data belonging to other users, demonstrating a critical authorization flaw.

Go deeper

Related to this question