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.

• ✓

  DOM-based XSS

  Why this is correct

  This vulnerability occurs entirely on the client-side when a web application's JavaScript code processes user-controllable data, often from the URL fragment (#) or query string (?), and writes it unsafely into the Document Object Model (DOM). If the client-side script dynamically generates HTML or JavaScript using this unvalidated input, an attacker can inject malicious code that executes within the victim's browser. The "reflection" happens within the browser's DOM, not necessarily on the server's response.

• ✓

  Reflected XSS

  Why this is correct

  Reflected Cross-Site Scripting occurs when a web application immediately echoes user-supplied input from an HTTP request back into the server's HTTP response without proper sanitization or encoding. An attacker crafts a malicious URL containing a script payload, which, when clicked by a victim, causes the server to embed the payload directly into the HTML page. The victim's browser then executes this script as part of the legitimate page content.

• ✗

  Self-XSS

  Why it's wrong here

  Self-XSS is not a vulnerability in the application's code but rather a social engineering tactic where a user is tricked into manually pasting malicious JavaScript code into their own browser's developer console. This attack relies on deceiving the victim into executing the script themselves, typically under the false pretense of gaining a benefit, and does not exploit any inherent flaw in how the web application handles user input or renders content.

• ✗

  Stored (persistent) XSS

  Why it's wrong here

  Stored XSS, also known as persistent XSS, involves injecting a malicious script into a web application's database or other persistent storage. Unlike reflected XSS, the payload is permanently saved on the server and subsequently delivered to other users who access the affected content, such as comments, forum posts, or profile fields. The question stem only mentions a parameter being "reflected," not stored for later retrieval by multiple users.

• ✗

  Blind XSS

  Why it's wrong here

  Blind XSS is a specialized form of stored XSS where the attacker injects a payload into an application, but the script's execution is not immediately visible or apparent to the attacker. Instead, the payload is stored and later triggered in a different, often internal or administrative, part of the application by a different user (e.g., an administrator viewing logs or support tickets). The attacker typically uses an out-of-band communication mechanism to confirm successful execution.

Go deeper

Related to this question