312-50 Question 358
Single answer▪ SQL Injection MethodologyDuring an authorized web application assessment, you find that the product search page sends requests like GET /search?category=books&id=12. When you append a single quote to the id parameter, the application returns a generic 500 error, but no database error details are shown. You also notice that changing the parameter to id=12 AND 1=1 returns the normal product page, while id=12 AND 1=2 returns a blank result set. The application does not reflect query output in the response body. Based on SQL injection methodology, what is the MOST appropriate next step to confirm and progress exploitation safely within scope?
- A
Proceed with boolean-based blind SQL injection by testing conditional expressions and inferencing database behavior from differences in application responses
- B
Switch immediately to UNION-based SQL injection and start enumerating table names by adding
UNION SELECTclauses until output appears - C
Assume the issue is only input validation related and stop testing because no verbose SQL error message is displayed
- D
Attempt stacked queries to write a web shell to disk, since a 500 error indicates full database command execution
Show answer and explanation
Correct answer: A
Explanation
This scenario points to inferential, specifically boolean-based blind, SQL injection. The key evidence is the difference in application behavior between logically true and false conditions appended to the parameter. In SQL injection methodology, the tester should first identify the injectable parameter, confirm injection with minimal-impact payloads, determine the injection type supported by the application, and then enumerate data using the available side channel. Because the application neither returns database errors nor reflects query results, boolean-based blind testing is the most appropriate next step. This approach is consistent with widely accepted web testing guidance such as the OWASP Web Security Testing Guide and OWASP SQL Injection Prevention guidance, which distinguish error-based, UNION-based, and blind inferential techniques based on application behavior.
- A. Correct.
Correct. The observed behavior is a classic indicator of boolean-based blind SQL injection:
AND 1=1preserves normal results, whileAND 1=2changes the application's behavior. Since query results are not directly displayed and verbose errors are suppressed, the proper methodology is to continue with inferential testing using true/false conditions to confirm injection and enumerate information safely. This aligns with standard SQL injection workflow: detect, confirm, determine type, and then enumerate using the channel actually available. - B. Incorrect.
Incorrect. UNION-based SQL injection depends on the application's response reflecting query results in a way the tester can see. In this scenario, the application does not display query output, so jumping directly to UNION-based enumeration is not the most appropriate next step. A candidate might choose this because UNION attacks are common, but methodology requires selecting a technique consistent with the observed behavior.
- C. Incorrect.
Incorrect. Lack of detailed SQL error messages does not rule out SQL injection. Error suppression is common in production systems. The differing responses between
AND 1=1andAND 1=2are strong evidence of an injectable condition. This option reflects the misconception that visible database errors are required to validate SQL injection. - D. Incorrect.
Incorrect. Attempting stacked queries or file-write attacks is premature and unsafe from a methodology standpoint. First, not all database engines or drivers support stacked queries through the web application. Second, a generic 500 error does not prove arbitrary command execution capability. Proper CEH-style methodology emphasizes controlled confirmation and structured enumeration before attempting higher-impact actions, and only when explicitly permitted by scope.