PT0-002 Vulnerability Discovery and Analysis 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 (XSS)

  Why it's wrong here

  Cross-site scripting (XSS) is incorrect because XSS vulnerabilities occur when unvalidated user input is reflected or stored in HTML/JavaScript contexts and executed in the victim's browser. In this PHP source code review, the input is being concatenated directly into a SQL query string, which is evaluated by the database engine, not the client-side DOM. The injected payload would be interpreted as SQL syntax, not as a client-side script, so the impact is server-side database manipulation rather than script execution in a web page.

• ✗

  Path traversal

  Why it's wrong here

  Path traversal (directory traversal) is not the correct finding because that vulnerability involves insufficient validation of file path inputs, allowing an attacker to read or write arbitrary files by using sequences like '../' to escape the web root. In this case, the sink is a SQL query function (e.g., mysqli_query or PDO::query), not a filesystem function such as file_get_contents or fopen. The attacker-controlled value is used to alter the structure of a database statement, not a file system path, so it cannot be used to access files on the server.

• ✗

  Command injection

  Why it's wrong here

  Command injection is a distinct vulnerability where user-controlled data is passed to a system shell function (e.g., exec, system, or passthru), allowing the execution of arbitrary operating system commands. However, the code under review concatenates input into a SQL query, which is handled by the database management system, not by the operating system shell. Consequently, the attacker can manipulate SQL statements but cannot run OS commands, making this an SQL injection issue rather than a command injection flaw.

• ✓

  SQL injection

  Why this is correct

  SQL injection is the correct answer because the source code concatenates user-supplied input directly into a SQL query without using parameterized prepared statements or proper escaping. For example, a query built as "SELECT * FROM users WHERE username = '" . $_POST['user'] . "'" can be exploited with a payload like ' OR '1'='1 to bypass authentication or with UNION-based queries to extract sensitive data. This flaw allows an attacker to read, modify, or delete database contents, and in some cases execute stored procedures, depending on the database user's privileges. The remediation is to use prepared statements with bound parameters, which separate data from SQL code and prevent the attack.

Go deeper

Related to this question