312-50 Question 305
Single answer▪ Web App Hacking MethodologyDuring an authorized web application assessment, you discover that the application's search page sends requests such as GET /search?q=laptop. When you submit a single quote (') in the q parameter, the application returns a generic 500 error. You also notice that the response time for some crafted inputs changes significantly, but the application suppresses database error messages. The rules of engagement require you to minimize impact and avoid unnecessary data extraction. According to sound web app hacking methodology, what is the BEST next step to confirm whether the parameter is vulnerable to SQL injection?
- A
Use boolean-based and time-based SQL injection test payloads on the
qparameter to safely verify injection behavior without dumping data - B
Immediately run an automated SQL injection tool with full database enumeration enabled to identify all tables and users
- C
Switch to cross-site scripting payloads in the
qparameter because the 500 error proves the input is reflected in the browser - D
Modify the application's session cookie to impersonate another user, since SQL injection cannot be confirmed without visible database errors
Show answer and explanation
Correct answer: A
Explanation
In web app hacking methodology, testers typically proceed in a structured order: reconnaissance and mapping, input vector identification, initial probing, vulnerability confirmation, and only then controlled exploitation if permitted. In this scenario, the single quote causing a 500 error is a useful indicator, but not sufficient proof by itself because generic server errors can have multiple causes. Since the application suppresses DBMS errors, blind SQL injection techniques are the most appropriate way to confirm the issue. Boolean-based tests compare application behavior for true/false conditions, while time-based tests measure induced delays when content differences are not visible. This approach is consistent with OWASP testing guidance for SQL injection, which recommends safe, incremental validation rather than immediately performing high-impact enumeration. It also aligns with professional best practices and rules of engagement: confirm first, minimize impact, and avoid unnecessary data access.
- A. Correct.
Correct. When verbose database errors are suppressed, the appropriate next step is to use controlled boolean-based and/or time-based tests to determine whether the parameter affects backend SQL logic. This aligns with a disciplined web app testing methodology: identify the input vector, observe anomalous behavior, then validate the suspected vulnerability using low-impact techniques before attempting exploitation. For example, comparing responses to conditions that evaluate true versus false, or introducing a small database delay, can confirm SQL injection while respecting scope and minimizing risk.
- B. Incorrect.
Incorrect. Full automated enumeration is not the best next step because it increases impact and goes beyond confirmation. In a professional assessment, especially when the rules of engagement emphasize minimizing disruption, the tester should first validate the vulnerability with limited, targeted payloads. Enumeration may be appropriate later if explicitly authorized and necessary, but it is not the most methodical or least invasive confirmation step.
- C. Incorrect.
Incorrect. A 500 error after inserting a single quote may indicate malformed backend processing, including possible SQL injection, but it does not prove reflected input or XSS. Cross-site scripting testing is a different assessment path focused on client-side execution in the browser. Choosing XSS here reflects a common misconception that any input-related error implies browser-side injection, which is not supported by the observed behavior.
- D. Incorrect.
Incorrect. Session cookie manipulation is unrelated to confirming SQL injection in the
qparameter. Also, SQL injection does not require visible database errors to be confirmed; blind techniques exist specifically for cases where applications suppress error details. This option confuses authentication/session attacks with input-validation and server-side query testing.