You wish to protect your MySQL database against SQL injection attacks. Which method would fail to do this?

Question

Options

• Ainstalling and configuring the Connection Control plugin
• Bavoiding concatenation of SQL statements and user-supplied values in an application
• Cusing stored procedures for any database access
• Dusing PREPARED STATEMENTS

• A
  5% (1)
• B
  14% (3)
• C
  73% (16)
• D
  9% (2)

Explanation

Stored procedures alone do not guarantee protection from SQL injection - this is the method that fails. If a stored procedure internally builds queries by concatenating user-supplied input (e.g., using PREPARE/EXECUTE with dynamic SQL strings inside the procedure), the injection vulnerability persists. The procedure is just a wrapper; the dangerous pattern can exist inside it.

Why the distractors are wrong (i.e., why A, B, and D actually do help):

• A - The Connection Control plugin throttles repeated failed login attempts, reducing an attacker's ability to repeatedly probe and exploit injection vectors through brute-force style testing.
• B - Avoiding string concatenation of SQL with user input directly eliminates the root cause of SQL injection; no concatenation means no injection point.
• D - Prepared statements (parameterized queries) separate code from data at the protocol level, so user input is never interpreted as SQL syntax - the gold standard defense.

Memory tip: Remember "stored procedures are not magic shields." Ask yourself: what's inside the procedure? If it still stitches user input into a query string, it's just as vulnerable as inline SQL. Parameterization (option D) and avoiding concatenation (option B) are what actually break the attack chain.

No community discussion yet for this question.