SY0-701 Threats, Vulnerabilities, and Mitigations 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.

• ✗

  Reflected cross-site scripting, because the payload only appears in the current request response.

  Why it's wrong here

  Reflected cross-site scripting is non-persistent: the malicious payload is carried in a crafted request—such as a URL or form input—and the server immediately returns it in the response without saving it to a database. Here, the bio is stored in the application and later fetched whenever any employee views that profile, which means the payload persists and executes in other users' browsers at a later time. Therefore, the attack matches stored XSS, not reflected XSS.

• ✓

  Stored cross-site scripting, because the malicious script is saved and served to other users later.

  Why this is correct

  Stored XSS occurs when malicious script is persisted by the application, such as in a profile field, comment, or message. Every user who later loads the page receives the harmful content. The redirection to a fake sign-in page shows that the script is executing in other users’ browsers, which makes this a stored, not reflected, attack. Proper output encoding and input handling are needed to prevent it.

• ✗

  Command injection, because the script runs inside the web server process.

  Why it's wrong here

  Command injection occurs when an attacker manipulates input that is passed to an operating-system command executed by the server, such as in a shell call or system() invocation. In this scenario, the injected script is JavaScript that runs in the victim's browser after the profile page is loaded; it never executes as an OS command on the web server. The redirection to a fake sign-in page is a client-side effect, demonstrating a browser-based XSS attack rather than server-side command execution.

• ✗

  Session fixation, because the attacker wants the victim to use an old session ID.

  Why it's wrong here

  Session fixation is an attack that forces or tricks a victim into using a session identifier chosen by the attacker, usually by setting the session ID before authentication, so the attacker can later hijack the authenticated session. Nothing in this scenario involves manipulating or reusing a session token; the attacker instead saves a malicious script into a profile bio that runs when other users view it and redirects them to a credential-harvesting page. That behavior is characteristic of stored XSS, not a session-management attack.

Go deeper

Related to this question