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.

• ✗

  Cross-site scripting, because the attacker is trying to run code in the browser.

  Why it's wrong here

  Cross-site scripting (XSS) would require the unsanitized input to be rendered back to a browser in an HTML or JavaScript context, where it could execute script. In this login form, the input is instead concatenated into a database query and evaluated by the SQL engine, so the payload's effect is to modify the query's logic on the server side, not run code in the victim's browser. The attack succeeds because the backend is constructing SQL statements unsafely, bypassing authentication at the database layer rather than hijacking a client-side session.

• ✓

  SQL injection, because the input changes the meaning of the database query.

  Why this is correct

  SQL injection occurs when untrusted input is embedded into a query and alters the intended logic. The crafted string closes the original condition and adds a statement that evaluates as true, which can bypass authentication checks. This is a classic sign that the application is constructing queries unsafely instead of using parameterized statements or properly bound variables.

• ✗

  Broken session management, because the user is still logged in after leaving the page.

  Why it's wrong here

  Broken session management pertains to vulnerabilities in the lifecycle of an established session, such as predictable tokens, fixation, or improper expiration. Here, the flaw occurs during the authentication attempt itself: the crafted input causes the SQL query to return true without verifying credentials, so a session may never have been properly created before the compromise. Even if the user remains logged in afterward, that is a downstream consequence of an authentication bypass, not a weakness in how the application handles session IDs or timeouts.

• ✗

  Insecure deserialization, because the application accepts user input.

  Why it's wrong here

  Insecure deserialization vulnerabilities arise when untrusted data is deserialized into an object model, allowing an attacker to manipulate application logic or execute code via crafted object attributes. In this login form, the input is a plain-text string placed into a SQL statement, not a serialized payload such as PHP serialized data or a Java ObjectInputStream stream. The attack changes the query's boolean logic with SQL syntax, which is a defining characteristic of SQL injection rather than deserialization or any generic acceptance of user input.