312-50 Question 353
Single answer▪ SQL Injection ConceptsDuring an authorized web application assessment, you test a product search feature that sends requests like: GET /search?category=books&id=15. When you change the id parameter to 15' and submit it, the application returns a database error showing part of the SQL query. Further testing shows that adding AND 1=1 returns normal results, while AND 1=2 returns no results. The application suppresses output from additional SELECT columns, so UNION-based extraction is not practical. Which technique is the most appropriate next step to confirm and exploit this SQL injection in a controlled manner?
- A
Use boolean-based blind SQL injection by sending true/false conditions and inferring data from changes in the application's response
- B
Switch to a UNION SELECT payload immediately, because any visible SQL error guarantees UNION-based extraction will work
- C
Attempt ARP spoofing against the database server to capture SQL queries and credentials in transit
- D
Use reflected XSS payloads in the id parameter to force the browser to disclose the backend database contents
Show answer and explanation
Correct answer: A
Explanation
This scenario describes a classic SQL injection workflow: an input containing a quote triggers a database error, indicating unsanitized input is reaching the SQL parser, and boolean conditions alter the application's behavior, confirming that the query logic can be influenced. When direct output techniques such as UNION-based SQL injection are not viable because the application does not display the injected query results, boolean-based blind SQL injection is the appropriate technique. In practice, testers use true/false predicates to infer information such as database version, table names, or credential hashes one bit or character at a time. This aligns with widely accepted guidance from the OWASP Web Security Testing Guide and the OWASP SQL Injection Prevention Cheat Sheet, which distinguish between in-band techniques like UNION-based injection and inferential techniques like boolean-based blind SQL injection. From a defensive perspective, the presence of this flaw indicates the need for parameterized queries or prepared statements, input handling controls, least-privilege database accounts, and suppression of verbose database errors.
- A. Correct.
Correct. The tester has already observed behavior consistent with boolean-based blind SQL injection: a true condition (AND 1=1) returns normal results, while a false condition (AND 1=2) changes the application's response. Since UNION-based output is not practical because additional SELECT columns are not reflected to the user, the most appropriate next step is to continue with boolean-based inference to confirm exploitability and extract data in a controlled way. This is a standard approach when the application reveals different page states but does not directly print query results.
- B. Incorrect.
Incorrect. A visible SQL error can indicate injectable input, but it does not guarantee that UNION-based extraction is feasible. UNION-based SQL injection requires compatible column counts, data types, and, critically, a location in the application's response where the returned data is rendered. The scenario explicitly states that output from additional SELECT columns is suppressed, making UNION-based extraction impractical at this stage.
- C. Incorrect.
Incorrect. ARP spoofing is a network-layer attack used to intercept traffic on a local network segment; it is not an appropriate next step for confirming or exploiting a parameter-level SQL injection vulnerability in a web application assessment. It also changes the engagement scope and method significantly. The issue here is application input handling, not network interception.
- D. Incorrect.
Incorrect. Reflected XSS and SQL injection are different vulnerability classes. Injecting JavaScript into the id parameter would test for client-side output encoding issues, not backend database query manipulation. XSS does not force the server to reveal database contents through SQL execution. This option reflects a common misconception of mixing web vulnerability categories.