CEH Web Application and Injection Attacks Practice Question

A web application allows users to submit feedback that is stored in a database and later displayed to administrators. An attacker submits feedback containing <script>alert('stored')</script>. When an admin views the feedback page, the script executes. Which type of XSS is this?

⚠ Common exam trap

CEH often tests the confusion between stored and reflected XSS — candidates see a script tag and assume reflected, but the key differentiator is whether the payload is persisted server-side (stored) or echoed back from the immediate request (reflected).

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Stored XSS

Stored XSS occurs when malicious script is persisted on the server (e.g., in a database, comment field, or log) and later served to other users without proper output encoding. Here, the attacker's <script> payload is saved as feedback and executed when the admin views the page, which is the defining characteristic of stored (persistent) XSS. The payload executes in the admin's browser session, potentially stealing cookies or performing actions as the admin.

Answer analysis

Option-by-option breakdown

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

✗
Blind XSS
Why it's wrong here
Blind XSS is a specific sub-type of Stored XSS where the attacker does not directly observe the execution of their injected payload, often because it triggers on an internal administrative interface or a backend system. While the scenario describes a script being stored and executed by an admin, which *could* be blind, the question's phrasing focuses on the storage and execution mechanism rather than the attacker's visibility. Therefore, 'Stored XSS' is the more general and directly applicable classification for the described vulnerability.
✗
Reflected XSS
Why it's wrong here
Reflected XSS, also known as Non-Persistent XSS, occurs when a malicious script injected into an HTTP request is immediately 'reflected' back in the server's response to the user's browser without being permanently stored on the server. The payload is typically delivered via a URL parameter or form submission and executed only once by the victim who clicks a crafted link. This mechanism fundamentally differs from the described scenario where the script is explicitly *stored* in a database for later, persistent execution.
✓
Stored XSS
Why this is correct
Stored XSS, also known as Persistent XSS, is a severe web vulnerability where a malicious script is permanently saved on the target server, typically within a database, comment section, or feedback system. When a legitimate user, such as an administrator, later retrieves and views the compromised data, their browser executes the embedded script without their knowledge. This allows the attacker to compromise user sessions, deface websites, or redirect victims, making it a highly impactful vulnerability due to its persistence and widespread potential.
✗
DOM-based XSS
Why it's wrong here
DOM-based XSS is a client-side vulnerability where the malicious payload is executed due to modifications of the Document Object Model (DOM) environment within the victim's browser, rather than being directly injected into the server's response. The server does not process or store the malicious script; instead, the vulnerability arises from client-side scripts mishandling user-controllable data that alters the DOM. The question explicitly states the script is 'stored' and 'executed when loaded by an admin,' indicating a server-side storage and retrieval mechanism, which contradicts the client-side nature of DOM-based XSS.

Go deeper

CEH Web Application and Injection Attacks Practice Question

Why each option matters

Option-by-option breakdown

Related to this question