CEH Web Application and Injection Attacks Practice Question

A tester is reviewing a web application that builds SQL queries using string concatenation and places user input directly into the query text. The development team wants to eliminate the SQL injection class of vulnerability rather than patch individual reports. Which TWO measures should the tester recommend to the team? (Choose two.)

⚠ Common exam trap

The trap here is treating a web application firewall as a complete fix for SQL injection, when it is only a supplementary control that does not correct the vulnerable query construction.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Apply strict allowlist validation on input that is expected to have a known format, such as numeric identifiers or enumerated values.

Eliminating SQL injection at the class level requires fixing how queries are constructed. Parameterized queries bind input as data so it cannot change query syntax, and allowlist validation restricts fields with known formats. Together they address the root cause, whereas firewalls, credential storage, and verbose errors affect other concerns without removing the vulnerability.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Apply strict allowlist validation on input that is expected to have a known format, such as numeric identifiers or enumerated values.
Why this is correct
Where input has a predictable structure, allowlisting constrains it to expected values and removes the ability to inject syntax. Combined with parameterization, validation hardens fields such as identifiers and enumerated parameters, reducing the attack surface and catching malformed input before it reaches the query layer.
✗
Deploy a web application firewall rule set and rely on it as the sole control to block injection payloads.
Why it's wrong here
A WAF can add defense in depth and block known signatures, but it is bypassable through encoding, obfuscation, and novel syntax, and it does not fix the vulnerable code. Treating it as the sole control leaves the underlying flaw intact and is not a durable remediation for the injection class.
✗
Store database connection credentials in the application source code to simplify deployment and rotation.
Why it's wrong here
Hardcoding credentials in source increases exposure through repositories and build artifacts and does nothing to prevent injection. Credential handling is a separate concern, and this recommendation neither addresses query construction nor reduces the ability of an attacker to manipulate SQL statements.
✗
Enable verbose database error messages in production so developers can debug malformed queries faster.
Why it's wrong here
Verbose errors leak schema, query structure, and database type, which assists attackers in refining injection payloads. While debugging information is useful in development, exposing it in production worsens the security posture and does not remediate the underlying concatenation flaw.
✓
Use parameterized queries or prepared statements so that user input is bound as data rather than parsed as SQL syntax.
Why this is correct
Parameterized queries separate the query structure from the data, so user input is transmitted as a bound value and cannot alter the SQL grammar. This addresses the root cause of SQL injection across all input paths and is the primary recommended remediation for applications that currently concatenate input into query strings.

Go deeper

CEH Web Application and Injection Attacks Practice Question

Why each option matters

Option-by-option breakdown

Related to this question