PT0-002 Attacks and Exploits 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.

• ✗

  Stored XSS; risk of data theft from database

  Why it's wrong here

  Stored XSS requires the payload to be persisted by the server, such as in a database, and later delivered to other users when they load the stored content. In this test, however, the echoed parameter appears immediately in the same HTTP response, indicating a reflection from the request rather than storage. While stored XSS can indeed be exploited for database data theft, the immediate reflection scenario is the hallmark of reflected XSS.

• ✓

  Reflected XSS; risk of session hijacking

  Why this is correct

  Reflected XSS occurs when user-supplied input is immediately echoed back in the server's response without proper sanitization or encoding. The attacker crafts a malicious URL containing script payload and lures the victim into clicking it; when the page loads, the script runs in the victim's session. This allows the attacker to steal session cookies via document.cookie and send them off-site, facilitating session hijacking. Because the payload is not persisted on the server, delivery depends on the victim accessing the crafted link.

• ✗

  Blind XSS; risk of internal network scanning

  Why it's wrong here

  Blind XSS is a stored XSS variant where the payload is submitted and later executed in a different application context, such as an admin panel, not in the immediate response that the submitting user receives. In this scenario, the parameter is directly reflected in the same response, so the trigger is neither blind nor stored. The internal network scanning risk listed in the option is not the distinguishing characteristic; the key reason refutation is that the observed behavior is a direct reflection, not a delayed stored execution.

• ✗

  DOM-based XSS; risk of client-side logic bypass

  Why it's wrong here

  DOM-based XSS is executed entirely within the client-side JavaScript: the vulnerable script reads attacker-controllable data, such as the URL fragment, and writes it into the DOM without validation. In this test, the parameter appears in the server-generated response, proving that the server itself is reflecting the unescaped value. Therefore, the root cause is server-side reflection, not a client-side sink, and the risk of client-side logic bypass is not the primary concern here.

Go deeper

Related to this question