Cyber Security Quiz: Sql Injection And Mitigations
10 questions · exam conditions
0:00
Sql Injection And MitigationsQuestion 1 of 10

A login handler executes SELECT user_id FROM users WHERE username = ? AND password_hash = ? through a database prepared-statement API. Both placeholders are bound as strings. An attacker submits admin' OR '1'='1 as the username.

Assuming the database driver performs genuine parameter binding, what is the most accurate result?

The payload becomes part of the SQL condition, so the query authenticates the attacker whenever an administrator account exists.
The payload is rejected only if the application first removes apostrophes and SQL comment characters from the username.
The payload is compared as one username value, so its SQL-looking characters do not change the query structure.
The payload remains dangerous because parameter binding protects numeric values but cannot safely represent quoted string values.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Sql Injection And Mitigations

Practice Sql Injection And Mitigations in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Sql Injection And Mitigations, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A login handler executes SELECT user_id FROM users WHERE username = ? AND password_hash = ? through a database prepared-statement API. Both placeholders are bound as strings. An attacker submits admin' OR '1'='1 as the username.

Assuming the database driver performs genuine parameter binding, what is the most accurate result?

  1. The payload becomes part of the SQL condition, so the query authenticates the attacker whenever an administrator account exists.
  2. The payload is rejected only if the application first removes apostrophes and SQL comment characters from the username.
  3. The payload is compared as one username value, so its SQL-looking characters do not change the query structure. (correct answer)
  4. The payload remains dangerous because parameter binding protects numeric values but cannot safely represent quoted string values.
Explanation: When a question involves SQL injection and prepared statements, focus on how the database actually processes the query — specifically, whether user input can alter the query's logical structure. With genuine parameter binding, the database compiles the SQL template first, locking in its structure before any user data is ever inserted. The placeholders (?) tell the database engine exactly where data values will go. When admin' OR '1'='1 is bound as a string parameter, the driver transmits it to the database as a literal data value — not as SQL text to be parsed. The database compares the entire string admin' OR '1'='1 against stored usernames character-for-character. No account has that exact username, so authentication fails. This is why C is correct: the SQL-looking characters lose all syntactic meaning because query structure was already finalized. A describes classic SQL injection, but that attack only works when input is concatenated directly into a query string — not when prepared statements are used correctly. The scenario explicitly states genuine parameter binding, making A factually wrong for this context. B introduces a common misconception: that input sanitization (stripping apostrophes or comment characters) is what makes prepared statements safe. It isn't. Parameterization works independently of character filtering; the driver's binding mechanism is the protection, not preprocessing. D is a subtle trap suggesting prepared statements can't handle quoted strings safely. This is false — string parameters are among the clearest cases where binding works perfectly, since the driver handles escaping automatically and completely. Your study tip: whenever a question says "genuine parameter binding," that phrase is your signal that the query structure is immutable — no injected syntax can escape the data context.

Question 2

A development team uses an object-relational mapper (ORM). Most queries use typed methods, but one endpoint calls a raw-query feature with where("email = '" + request.email + "'"). The team argues that the ORM automatically protects all database access.

Which change most appropriately addresses the endpoint's risk?

  1. Use the ORM's placeholder or expression API to bind the email value rather than embedding it in the raw condition. (correct answer)
  2. Keep the raw condition but HTML-encode the email value before concatenating it into the SQL fragment.
  3. Keep the raw condition because ORM-generated execution automatically parameterizes strings already present in the fragment.
  4. Validate that the email contains an at-sign and period, then concatenate it because valid emails cannot contain SQL syntax.
Explanation: Whenever you see a question involving raw SQL construction inside an ORM, recognize that this is fundamentally a SQL injection problem. The ORM's typed methods are safe precisely because they use parameterized queries under the hood — but the moment you drop into a raw-query feature and concatenate user input as a string, you have bypassed that protection entirely. The ORM brand is irrelevant; the vulnerability lives in how the query is assembled, not which library executes it. The right fix, choice A, is to use the ORM's own placeholder or expression API (e.g., where("email = ?", request.email) or an equivalent binding syntax). This separates the SQL structure from the data value, so the database engine treats the email as a literal string — never as executable SQL — regardless of what characters it contains. Choice B is a classic trap: HTML-encoding neutralizes characters like < and > for web output, but SQL injection uses characters like ', --, and ;. HTML encoding does nothing to stop SQL injection. Choice C is factually wrong — dropping raw string fragments into a query does not trigger automatic parameterization; the ORM passes the pre-built fragment directly to the database engine, injected content and all. Choice D fails because email validation via simple pattern matching is not a security boundary. An attacker can craft inputs that satisfy basic rules (containing @ and .) while still embedding malicious SQL fragments after or around those characters. Your study takeaway: parameterization is the only reliable defense against SQL injection. Any time user input is concatenated into a query string — even inside an ORM, even after validation — treat it as a vulnerability.

Question 3

An endpoint accepts a list of product IDs and currently creates SELECT * FROM products WHERE product_id IN ( followed by the comma-joined request strings and ). The number of IDs varies with each request.

Which implementation best preserves variable-length functionality while mitigating SQL injection?

  1. Generate one placeholder per list element and bind each validated ID separately, while also defining safe behavior for an empty list. (correct answer)
  2. Bind the complete text 1,2,3 as a single placeholder inside IN (?), relying on the database driver to split and interpret the comma-separated value correctly.
  3. Join the values after escaping apostrophes, because comma-separated numeric lists do not support ordinary string injection payloads.
  4. Concatenate the list after removing spaces and semicolons, then reject any request whose final SQL string contains comment markers or UNION keywords.
Explanation: When you see a question about SQL injection and dynamic queries, focus on parameterized queries (prepared statements) — the gold standard defense. The core principle is that user-supplied data must never be interpreted as SQL syntax. The challenge with IN (...) clauses is that the number of placeholders must match the number of values, which requires a bit of extra logic compared to single-value queries. Answer A is correct because it generates exactly one ? placeholder per validated list element, then binds each value individually. The database driver treats each bound value as pure data — never as executable SQL — regardless of its content. Handling the empty-list edge case separately is also important, since IN () is invalid SQL that could cause unintended errors or behavior. Answer B exploits a common misconception: that you can bind an entire comma-separated string as a single placeholder inside IN (?). Database drivers don't split or interpret that string — the query would either fail or match nothing, and it is not a valid injection defense. Answer C is dangerous because escaping apostrophes alone is insufficient. Numeric-looking inputs like 1 OR 1=1 require no apostrophes whatsoever, meaning injection payloads can still manipulate query logic without any string delimiters. Answer D is a classic blocklist/denylist trap. Filtering out spaces, semicolons, comments, and UNION keywords relies on anticipating every possible attack pattern — an impossible task. Attackers routinely bypass blocklists using encoding, case variation, or alternative syntax. Study tip: Any time you see an answer involving escaping, filtering, or keyword blocklisting, treat it with suspicion. Parameterized queries with bound parameters are almost always the correct defense for injection vulnerabilities on security exams.

Question 4

An application calls a stored procedure using a bound parameter: CALL FindCustomer(?). Inside the procedure, the implementation constructs SELECT * FROM customers WHERE last_name = ' followed by the procedure argument and then executes the resulting string dynamically.

Which assessment and remediation are most accurate?

  1. The call is safe because binding at the application boundary protects the value throughout all later database operations.
  2. The procedure is vulnerable because it rebuilds SQL text; it should use static SQL or bind the value in the dynamic statement. (correct answer)
  3. The procedure is safe if the application account has only permission to execute the procedure and cannot select the table directly.
  4. The procedure is vulnerable only to stacked statements, so disabling multiple statements fully addresses the identified weakness.
Explanation: When evaluating SQL injection vulnerabilities, you need to trace data flow through every layer, not just the entry point. A bound parameter at the application layer prevents injection at that specific call — but if the database then unpacks that value and concatenates it into a new SQL string, the protection evaporates entirely. The vulnerability lives wherever string construction happens, regardless of what came before. This is exactly the trap in this scenario. The stored procedure receives the parameter safely, then manually builds SELECT * FROM customers WHERE last_name = ' + argument and executes it dynamically. At that moment, an attacker's input like ' OR '1'='1 is evaluated as live SQL syntax. The correct answer is B because it accurately diagnoses the root cause — dynamic string construction inside the procedure — and prescribes the right fix: use static SQL (where the query structure never changes) or properly bind the value within the dynamic statement itself. A is wrong because it assumes the application-layer binding creates end-to-end protection. It doesn't. Binding only protects the specific execution point where it's applied. C is wrong because permissions control access, not code execution safety. The procedure itself can still be exploited, and the injected query runs under whatever privileges the procedure holds. D is wrong because SQL injection is far broader than stacked statements. Attackers can manipulate logic with OR 1=1, extract data with UNION SELECT, or cause errors — all within a single statement. Disabling multiple statements addresses one narrow vector while leaving the vulnerability wide open. Your study tip: always ask "where is the SQL string assembled?" — that's where injection risk lives, not where the data entered the system.

Question 5

A product search executes SELECT product_id FROM products WHERE name LIKE ? and binds the value formed by placing % before and after the user's search term. A user enters %, causing the search to return nearly every product.

Which explanation best distinguishes the observed behavior from SQL injection?

  1. It is SQL injection because the user-controlled percent sign modifies the database statement's parsed SQL structure.
  2. It is not SQL injection; the value remains bound data, although unescaped LIKE wildcards can broaden matching semantics. (correct answer)
  3. It is SQL injection only because the application adds its own percent signs before binding the completed search pattern.
  4. It is not SQL injection because percent signs are ignored inside bound values and therefore cannot affect query results.
Explanation: When distinguishing SQL injection from other input-handling problems, the critical question is: did the user's input change the structure of the SQL statement itself, or did it only affect the data being compared? Parameterized queries (prepared statements with bound values) are specifically designed to enforce that separation. Here, the query uses a ? placeholder, meaning the database engine parses and compiles the SQL before any user data is substituted. The user's % is treated purely as a string value — it never touches the query's logical structure. B is correct because it accurately captures both truths simultaneously: no SQL injection occurred (the structure is intact), and the % wildcard still meaningfully broadens the LIKE match, returning far more rows than intended. This is a real vulnerability — just not SQL injection. It's better categorized as improper input validation. A is wrong because it claims the user "modifies the parsed SQL structure," which is precisely what parameterization prevents. The parsing happens before the value is ever bound — this is the entire point of prepared statements. C is wrong because it misidentifies the application's own % additions as the source of injection. Those additions are part of the developer's intended pattern-building logic, not user-controlled SQL manipulation. D is wrong in the opposite direction — it overcorrects into a false sense of safety. Bound % values absolutely can affect query results through LIKE semantics; they just can't alter SQL structure. Claiming they're "ignored" is factually incorrect. As a study tip: when you see parameterized queries, remember that security ≠ correctness. A query can be injection-safe but still behave unexpectedly due to unvalidated wildcard characters.

Question 6

A database driver has been configured to reject queries containing multiple statements. The application nevertheless constructs SELECT order_id FROM orders WHERE customer = ' followed by an untrusted request value and a closing apostrophe.

What security effect does disabling multiple statements provide in this scenario?

  1. It eliminates SQL injection because an attacker must execute a second statement to affect the original query's meaning.
  2. It prevents only string-based injection, while numeric and date fields must still use parameterized statements.
  3. It limits stacked-query attacks, but the attacker may still alter the predicate within the permitted single statement. (correct answer)
  4. It converts untrusted text into one bound value, although database error messages may still reveal query details.
Explanation: When evaluating a SQL injection defense, ask yourself: what does this control actually block, and what attack surface remains? Disabling multiple statements (sometimes called "stacked queries") prevents an attacker from appending a second statement like ; DROP TABLE orders--, but it says nothing about what the attacker can do within the one statement that is still permitted. In this scenario, the application still concatenates untrusted input directly into the query string inside a string literal context. An attacker can close the apostrophe, inject conditions like ' OR '1'='1, and completely alter the WHERE predicate — all within a single statement. The database driver happily executes it because no second statement was detected. This is exactly what C describes: stacked-query attacks are limited, but single-statement predicate manipulation remains fully exploitable. A is wrong because it assumes injection requires a second statement to "affect the query's meaning." That's false — injecting ' OR 1=1-- rewrites the predicate of the original single statement without stacking anything. B is wrong because the restriction on multiple statements has nothing to do with data types like numeric or date fields; that's a separate concern about parameterization, which this scenario explicitly hasn't implemented. D describes parameterized queries — binding untrusted input as a value — which is not what disabling multiple statements does. These are two completely different mechanisms. The study tip here: never conflate one defense with complete protection. Exam questions frequently describe a partial control and ask you to identify its residual risk. Always trace the full attack path — if unsanitized string concatenation survives, injection survives with it.

Question 7

An API retrieves active accounts using the query SELECT id, name FROM accounts WHERE active = ? ORDER BY ?. The application binds true to the first placeholder and the client-supplied value created_at to the second. In testing, the database either reports an error or returns rows without the expected sorting.

Which change most securely provides client-selectable sorting while preserving the intended query behavior?

  1. Concatenate the requested sort value after removing quotes and semicolons, while continuing to bind the active value.
  2. Map approved sort keys to hard-coded column names, concatenate only the mapped name, and bind all data values. (correct answer)
  3. Bind the requested sort value as a string and cast the placeholder to a database identifier in the query.
  4. Escape the requested sort value with the database string-escaping function before placing it after ORDER BY.
Explanation: When a query needs user-influenced structural elements like column names rather than data values, you're dealing with a classic SQL injection boundary problem. Parameterized binding protects data values perfectly, but most databases won't accept a bound parameter as an identifier — which is exactly why the query in the passage fails or sorts incorrectly when created_at is bound to the second placeholder. The safest solution is option B: maintain an explicit server-side allowlist that maps client-supplied keys (like "created_at") to hard-coded column names, then concatenate only that pre-approved, internally controlled string into the query. The user's raw input never touches the SQL — only your code's own trusted constant does. Data values like active = true continue to use binding normally. This eliminates injection risk while delivering the correct behavior. Option A is dangerous because stripping quotes and semicolons is an incomplete denylist approach. Attackers can often bypass such filters using alternate syntax, comments, or encoding tricks — there's always something you forget to block. Option C sounds clever but doesn't work in practice: databases parse placeholders as string literals, not identifiers, so casting a bound value to a column name is either unsupported or still injectable depending on implementation. Option D applies string-escaping to what should be an identifier, not a string. Escaping prevents quote injection inside string literals — it offers no reliable protection when the value is placed structurally in a query without quotes. Study tip: Whenever you see "user controls a column name or sort order," your instinct should be "allowlist + concatenate the mapped constant, not the raw input." Parameterization handles values; allowlists handle structure.

Question 8

A legacy endpoint obtains an accountId from a request. A strict parser accepts only decimal digits, converts the result to a bounded integer, and the application concatenates that integer into SELECT balance FROM accounts WHERE account_id = followed by its decimal representation.

Which review finding is the most precise?

  1. The shown path is immediately injectable because every use of SQL concatenation permits arbitrary syntax regardless of prior conversion.
  2. The strict conversion prevents injection and also ensures that callers cannot access another user's valid account identifier.
  3. The path is safe only when the account identifier is enclosed in quotes and escaped with a string-literal escaping function.
  4. The strict conversion blocks SQL syntax in this path, but parameterization is still preferable to avoid fragile future assumptions. (correct answer)
Explanation: When evaluating SQL injection risk, you need to separate two distinct questions: does this specific path allow injection right now? and is this the best long-term approach? Conflating them leads to imprecise security findings. Here, the strict parser accepts only decimal digits and converts them to a bounded integer before concatenation. Because a pure integer cannot contain SQL metacharacters — no quotes, no semicolons, no comments — the concatenated query is structurally safe on this path. That makes D the most precise finding: the conversion genuinely blocks injection here, yet parameterized queries (prepared statements with bound parameters) are still the superior practice. Why? Because parameterization is robust by design — it doesn't depend on the correctness of upstream validation logic that could be bypassed, refactored, or misapplied in a future code change. A is wrong because it overstates the risk. Not every SQL concatenation is automatically injectable; the claim that "prior conversion never matters" is factually incorrect. An integer-only value truly cannot smuggle SQL syntax. A represents a common overcorrection where reviewers flag concatenation reflexively without analyzing what is actually being concatenated. B is wrong for a subtler reason: preventing SQL injection is entirely separate from enforcing authorization. Even with perfect input sanitization, nothing stops a caller from supplying another user's valid integer account ID. That's an access-control (IDOR) problem, not an injection problem, and conflating them is a category error. C is wrong because it prescribes a string-escaping approach, which is irrelevant here — the value is an integer, not a string literal, and quoting it introduces unnecessary complexity rather than improving safety. Your study tip: when a question asks for the "most precise" finding, look for the answer that is accurate in both directions — neither understating nor overstating the risk.

Question 9

A profile service safely inserts display names with INSERT INTO profiles(display_name) VALUES (?). A separate reporting job later reads each display name and concatenates it into SELECT event_id FROM events WHERE actor_name = ' followed by the stored value. Reports are generated only by administrators.

What is the best security conclusion?

  1. The workflow is safe because the display name was parameterized when originally inserted into the profiles table.
  2. The workflow is safe because only administrators trigger the report, even though stored names influence its query.
  3. The reporting job has a second-order injection risk and must parameterize the value when it executes the later query. (correct answer)
  4. The reporting job needs output encoding only, because stored database values cannot become SQL instructions after retrieval.
Explanation: When a value is safely stored in a database doesn't mean it's safe forever — this question tests your understanding of second-order (stored) SQL injection, where malicious input is injected at one point and executed at a different, later point in the application's workflow. Here's the core problem: even though the display name was correctly parameterized during the INSERT, the reporting job retrieves that stored value and concatenates it directly into a new SQL query string. If an attacker registered a display name like ' OR '1'='1, it would sit harmlessly in the database — but the moment the reporting job builds its SELECT query using string concatenation, that stored value becomes live SQL. The parameterization of the original insert offers zero protection for this second query. Answer C is correct because the fix must happen at the point of execution: the reporting job must treat the retrieved value as untrusted input and use a parameterized query or prepared statement. A is wrong because it conflates where data was safely stored with where it is safely used. Parameterization protects only the query it belongs to — it doesn't sanitize the data itself for future use. B is wrong because access controls don't neutralize injection vulnerabilities; administrators can still trigger malicious logic, and restricting who runs a query doesn't fix how the query is constructed. D is wrong because output encoding addresses rendering in a browser (XSS prevention), not SQL injection — and the claim that database-stored values "cannot become SQL instructions" is simply false. Your study tip: whenever you see data traveling from one query into a different query later, mentally flag it as a second-order injection risk — parameterize at every execution point, not just the first.

Question 10

A public application concatenates request values into SQL statements. Its web application firewall blocks common strings such as UNION SELECT, apostrophe-based tautologies, and SQL comment markers. Security testing finds no successful payloads using the firewall's current rule set.

Which recommendation most directly addresses the underlying SQL injection risk?

  1. Keep concatenation but expand the firewall signatures whenever a new encoded or database-specific payload is discovered.
  2. Suppress database error messages and continue relying on the firewall to prevent syntactically valid malicious statements.
  3. Move the existing validation into client-side JavaScript so malformed values are rejected before requests reach the firewall.
  4. Replace concatenation with server-side parameterized queries and retain the firewall only as a defense-in-depth control. (correct answer)
Explanation: When a question asks how to "most directly address the underlying risk," that's your cue to distinguish between fixing a root cause versus managing symptoms. SQL injection exists because user-supplied input is treated as executable code — that's the root cause. Any solution that doesn't break that relationship is just mitigation layered on top of a broken foundation. Parameterized queries (also called prepared statements) solve the problem structurally: the database receives the query structure and the user data as separate, distinct elements, so input can never be interpreted as SQL syntax — no matter how cleverly it's encoded or obfuscated. That's why D is correct. Retaining the firewall afterward provides defense-in-depth, but the firewall is no longer the last line of defense against a structural flaw. A is wrong because it treats the firewall as the primary fix. Expanding signatures is a perpetual arms race — attackers constantly discover new encodings, dialect-specific syntax, and obfuscation techniques that bypass rules. You'll always be one step behind. B is wrong for a similar reason: suppressing error messages removes useful information for an attacker (good hygiene), but it does nothing to prevent a successful injection — it just makes blind injection harder, not impossible. C is a classic trap: client-side validation is trivially bypassed by anyone using a proxy tool or simply disabling JavaScript. Validation logic must live on the server to be trustworthy. As a study tip, watch for questions that offer "fix the symptom" options alongside "fix the cause" options. On security exams, the answer that eliminates the vulnerability at the architectural level almost always outranks compensating controls.