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.

• ✗

  Implementing stored procedures with dynamic SQL

  Why it's wrong here

  Implementing stored procedures alone does not guarantee protection against SQL injection, especially when they incorporate dynamic SQL. If the dynamic SQL is constructed by concatenating user input directly into the query string, it remains highly susceptible to injection attacks. The security benefit of stored procedures is primarily realized when they use parameterized queries internally, not when they simply encapsulate vulnerable dynamic SQL.

• ✗

  Disabling error messages

  Why it's wrong here

  Disabling error messages is a security hardening practice that prevents attackers from gaining valuable information about database structure or query failures. However, it is not an effective defense against SQL injection itself. An attacker can still execute malicious queries; they simply won't receive explicit error feedback, which might make exploitation slightly more difficult but does not prevent the underlying vulnerability.

• ✓

  Using an ORM that generates parameterized queries

  Why this is correct

  Object-Relational Mappers (ORMs) provide an effective defense against SQL injection by abstracting database interactions and typically generating parameterized queries. Instead of concatenating user input directly into SQL strings, ORMs bind input values as parameters, ensuring they are treated as data and not executable code. This fundamental separation prevents malicious input from altering the query's structure, thereby neutralizing injection attempts.

• ✓

  Using prepared statements with parameterized queries

  Why this is correct

  Using prepared statements with parameterized queries is a highly effective and widely recommended defense against SQL injection. This method involves sending the SQL query structure to the database server separately from the user-supplied data. The database then compiles the query plan, treating all subsequent bound parameters purely as data values, regardless of their content. This strict separation ensures that malicious input cannot modify the query's logic or intent.

• ✗

  Escaping user input with addslashes()

  Why it's wrong here

  Escaping user input with functions like addslashes() is an unreliable and often insufficient defense against SQL injection. While it attempts to neutralize certain special characters, it is highly dependent on the specific database system, character encoding, and the context in which the escaped string is used. Attackers can frequently bypass such simplistic escaping mechanisms, especially with advanced injection techniques or when character sets are mishandled, leading to vulnerabilities.

Go deeper

Related to this question