CEH Web Application and Injection Attacks Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Increase WAF sensitivity to block base64-encoded strings

  Why it's wrong here

  Increasing WAF sensitivity to block base64-encoded strings is an insufficient defense because attackers employ numerous encoding and obfuscation techniques beyond just base64 to bypass WAF rules. WAFs operate on signature matching and heuristic analysis, which can often be evaded by novel payloads, polymorphic code, or simply by crafting queries that do not trigger specific WAF patterns. This approach is reactive and provides only a partial, signature-based defense rather than a fundamental prevention against SQL injection.

• ✓

  Implement prepared statements with parameterized queries

  Why this is correct

  Implementing prepared statements with parameterized queries is the most robust solution because it fundamentally separates SQL code from user-supplied data. The database engine first compiles the SQL query structure, defining placeholders for input, before any user data is introduced. Subsequently, user input is bound to these placeholders as literal values, ensuring it is never interpreted as executable SQL code, thereby eliminating the possibility of SQL injection attacks.

• ✗

  Disable error messages to hide database errors

  Why it's wrong here

  Disabling error messages to hide database errors is a security-by-obscurity measure that does not prevent SQL injection itself. While it can prevent attackers from gaining valuable information about the database structure or query failures (which aids error-based SQL injection), the underlying vulnerability remains exploitable. Malicious SQL payloads can still be executed, potentially leading to data compromise or unauthorized access, even if no error feedback is provided to the attacker.

• ✗

  Use a more restrictive input validation regex

  Why it's wrong here

  Using a more restrictive input validation regex is an unreliable primary defense against SQL injection because it is inherently difficult to create a regex that comprehensively covers all possible malicious inputs and encoding variations. Attackers can often find ways to encode or obfuscate payloads that bypass specific regex patterns, or they can exploit edge cases not considered during validation. While input validation is a valuable layer of defense, it should not be solely relied upon to prevent sophisticated injection attacks.

Go deeper

Related to this question