312-50 Question 328
Single answer▪ Perform Injection/Input Validation AttacksDuring an authorized web application assessment, you test a product search feature that sends requests like GET /search?q=laptop. The application returns normal results for q=laptop, but when you send q=', the server responds with a database error indicating malformed SQL syntax. You need to confirm whether the parameter is vulnerable to SQL injection while minimizing impact on the production system and avoiding destructive actions. Which approach is the most appropriate next step?
- A
Submit a time-based blind SQL injection payload such as
q=laptop' WAITFOR DELAY '0:0:5'--or the DBMS-equivalent to observe a measurable delay without modifying data - B
Attempt
q=laptop'; DROP TABLE products;--to prove exploitability with a definitive database-side effect - C
Run a full denial-of-service test against the search endpoint to determine whether the database layer is resilient to malformed input
- D
Conclude the issue is only input validation related and not SQL injection because the application displayed a database error instead of returning search results
Show answer and explanation
Correct answer: A
Explanation
The safest and most appropriate next step is to confirm the suspected SQL injection using a non-destructive technique. In this scenario, the single quote causing a SQL syntax error strongly suggests that unsanitized input is being incorporated into a backend query. A time-based payload is commonly used to verify execution while minimizing impact, especially when testers want to avoid data extraction or modification. Best practices from OWASP guidance on SQL Injection Prevention emphasize parameterized queries and proper input handling as defenses, while penetration testing methodology emphasizes using the least invasive technique necessary to prove the issue. Destructive payloads such as DROP TABLE are not appropriate in normal authorized testing because they can damage integrity and availability. Likewise, a DoS test does not answer whether the parameter is injectable. The database error itself is valuable evidence of improper input handling and excessive error disclosure, both of which increase confidence that SQL injection is possible.
- A. Correct.
Correct. A time-based blind SQL injection test is a controlled, non-destructive way to confirm whether user input is being executed in a backend SQL query. Using a delay function appropriate to the target DBMS can help verify injection even when output is limited or inconsistent. In an authorized assessment, confirming execution through timing is safer than using payloads that alter or delete data.
- B. Incorrect.
Incorrect. Although this would demonstrate severe impact, it is destructive and inappropriate for a production assessment unless explicitly approved in writing and tightly scoped. Ethical hacking practice and common penetration testing rules of engagement require minimizing harm and avoiding payloads that modify or destroy data when safer validation methods exist.
- C. Incorrect.
Incorrect. A denial-of-service test does not directly validate SQL injection and introduces unnecessary operational risk. The scenario is about confirming an injection flaw in a specific input parameter, so availability testing is not the appropriate next step.
- D. Incorrect.
Incorrect. A verbose SQL error after entering a single quote is a classic indicator of possible SQL injection, not evidence against it. Error-based behavior often suggests unsanitized input is reaching the SQL parser. The misconception here is confusing information leakage with a purely cosmetic input validation issue.