312-50 Question 367
Select 2▪ SQL Injection CountermeasuresA retail company discovers that its customer search page is vulnerable to SQL injection because the application builds queries by concatenating user input into a WHERE clause. The development team must fix the issue quickly without removing the search feature, and they also want a control that still protects the database if a coding mistake reappears later. Which TWO actions provide the most effective countermeasures in this scenario?
- A
Replace dynamic string concatenation with parameterized queries or prepared statements in the application code
- B
Escape single quotes in user input and rely on client-side JavaScript validation before submitting the search request
- C
Restrict the application's database account to only the minimum permissions required for the search function
- D
Hide database error messages from users, but keep the current query-building logic unchanged
- E
Base64-encode all search input before sending it to the server so SQL meta-characters are not visible
Show answer and explanation
Correct answers: A, C
Explanation
The best answer is to combine a primary prevention control with a compensating defense-in-depth measure: use parameterized queries/prepared statements and restrict database privileges. Prepared statements are widely recommended by secure coding guidance, including the OWASP SQL Injection Prevention Cheat Sheet, because they ensure user input is handled as data rather than executable SQL. Least privilege is also a key best practice because it reduces the blast radius of a successful injection by limiting what the application account can do. Error suppression can help reduce reconnaissance but does not fix the vulnerability. Client-side validation and ad hoc escaping are insufficient because attackers can bypass browser-side controls and escaping is easy to implement incorrectly. Encoding schemes such as Base64 do not provide injection protection because they do not change how SQL statements are ultimately constructed on the server.
- A. Correct.
Correct. Parameterized queries (prepared statements) separate SQL code from user-supplied data, which is one of the primary and most reliable defenses against SQL injection. Instead of treating input as executable SQL syntax, the database driver binds it as data. This directly addresses the root cause: unsafe query construction through string concatenation.
- B. Incorrect.
Incorrect. Escaping quotes alone is error-prone and often incomplete because SQL injection is not limited to single-quote abuse, and different databases and encodings can introduce bypasses. Client-side JavaScript validation is also not a security boundary because an attacker can intercept or modify requests before they reach the server. This option reflects the common misconception that browser-side checks are sufficient protection.
- C. Correct.
Correct. Applying the principle of least privilege to the database account limits the impact if SQL injection occurs again. For a search-only feature, the account may need only SELECT access to specific tables or views, not INSERT, UPDATE, DELETE, DROP, or administrative privileges. This does not replace secure coding, but it is an important defense-in-depth countermeasure.
- D. Incorrect.
Incorrect. Suppressing verbose database errors is good practice because it reduces information disclosure, but by itself it does not prevent SQL injection. If the application still concatenates input directly into SQL statements, the vulnerability remains exploitable even if the attacker receives less feedback.
- E. Incorrect.
Incorrect. Base64 encoding is not a security control against SQL injection. The server must decode the value before using it, leaving the application in the same vulnerable state if it still concatenates the decoded input into SQL. This option is a plausible but incorrect misunderstanding that encoding data changes its trustworthiness.