Skip to content
ScopefileGet the app

Module 15Domain 5 of 9Web Application Hacking

SQL injection: types, signs and the fix that works

SQL injection happens when input an application receives ends up being run by the database as part of a query. The fix is a query whose structure is fixed before any data arrives. Module 15 is one of three modules in Domain 5, Web Application Hacking, which carries 14% of the exam under blueprint v5.0 (checked Oct 11, 2026). Each class below is named by what a defender can observe, and each control by whether it removes the cause.

Exam
312-50
Domain
5 of 9
Domain weight
14%
This file
~5%
Targets
17

The classes, sorted by how the result comes back

SQL injection classes, the weakness each relies on, and what a defender sees
ClassWhat it isWeakness it relies onWhat the defender sees
Error-based (in-band)Database error text reaches the response and carries details of the query or schema.Queries built by joining strings, plus verbose error handling.Database error messages in pages or application logs, often in bursts from one source.
UNION-based (in-band)A second result set is merged into the legitimate one and shown on the normal page.Concatenated queries whose results are displayed to the user.Unusually large responses and data from unrelated tables showing up in ordinary pages.
Boolean blindNothing is displayed; the page simply behaves differently when a hidden condition is true or false.The same concatenated query, as the in-band classes.Long runs of near-identical requests against one parameter, with response sizes that flip between two values.
Time-based blindThe only signal is how long the response takes.A concatenated query and a database that will wait when asked.Clusters of slow responses tied to a single parameter and matching spikes in database wait time.
Out-of-bandThe database is induced to send results over a separate channel, such as DNS or HTTP.A database server that is allowed to open outbound connections.A database host making DNS lookups or outbound connections it never makes in normal operation.
Second-orderInput is stored first and only becomes dangerous when a later query reuses it.Code that trusts data because it came from the application's own tables.The alert fires on a different feature from the one where the data was submitted.

In-band, blind (inferential) and out-of-band are the three families. The SQL injection types breakdown takes each family one level deeper.

Controls by class

Four defenses against SQL injection and where each one stops
PointParameterized queriesStored proceduresEscaping and blocklistsWAF rules
What it changes (differs)Query structure is fixed; input is bound as dataQuery logic moves into the databaseInput is altered before it is joined into the queryRequests are inspected before they reach the app
Removes the root cause (differs)YesOnly if the procedure builds no dynamic SQL insideNoNo
Typical failure (differs)Table or column names cannot be bound, so they need an allow-listA procedure that concatenates its own parametersOne missed character set or database dialect reopens the holeA variant the signatures do not match
Label (differs)Primary defenseAcceptable when written safelyWeak, last resortLayered filtering in front of the app
Produces alerts (differs)NoNoNoYes

Tinted rows marked ≠: at least one of the 4 differs from the others.

Of the four, only bound parameters fix the query itself.

Reading the clues in a scenario

A scenario either gives a symptom and asks for a class, or gives a weakness and asks for a control. Decide which kind it is first.

Clues and what they point to

  • Database error text in a user-facing page: an in-band exposure, and also an error-handling failure that needs its own fix.
  • Response time that tracks one parameter: time-based blind. Nothing is displayed, so the timing is the leak.
  • A database server reaching the internet: out-of-band. Pair it with egress filtering for database hosts and DNS monitoring.
  • Bad data surfacing far from where it entered: second-order. The fix is binding parameters in every query, including those that read the application's own stored data.

Evasion, from the defender's chair

The blueprint lists evasion techniques as a Module 15 topic. The point is why signature matching is fragile: the same query logic can be written many ways, so a filter that looks for exact strings misses variants. The defensive answers are to normalize input before inspection, keep WAF signatures current and, above all, bind parameters, so that slipping past a filter changes nothing.

One flaw, several interpreters

Every injection flaw is untrusted input reaching an interpreter. What changes is the interpreter. In SQL injection, the database runs it. In cross-site scripting, the victim's browser runs it, which is why the XSS, CSRF and SSRF comparison sits next to this file. Command injection reaches the operating system shell, and LDAP, XPath and NoSQL injection reach their own query engines. Settle the interpreter question before you weigh the controls. The web application module covers the injection flaws that never touch a database.

Rules of engagement

Injection testing touches live data, so it needs written authorization that names the applications in scope.

Your skip-list

Function names for specific databases, tool switches and catalogs of filter-evasion encodings. They take hours to memorize and pay back little. Spend that time drilling until classifying a scenario and naming its control takes a few seconds.

Classify, then defend

For each target, first ask where the input ends up and what the defender can actually see. The class and the control follow from those two answers.

Answered 0/17Hits 0

T-01

A web application interfaces with a backend database. Which combination of controls provides the most comprehensive defense-in-depth posture against SQL injection vulnerabilities?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. ACorrect: parameterized queries remove the root cause, allow-list validation narrows accepted input, and least privilege limits what any surviving flaw can reach in the database.
  2. BOutput encoding defends against cross-site scripting, randomized database names are mere obscurity, and network firewalls cannot inspect query logic inside application traffic.
  3. CA WAF and input filtering are useful extra layers, but obfuscation adds no real protection and none of these fix queries built by string concatenation.
  4. DComplex regex validation is brittle and easy to get wrong, network segregation does not stop injected queries, and hashing protects stored secrets rather than query structure.
T-02

SQL injection vulnerabilities often occur due to improper handling of what?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. AServer configuration matters for hardening, but SQL injection arises in application code that mixes untrusted input into query text.
  2. BCorrect: SQL injection happens when user-supplied input is concatenated into queries without parameterization, letting data be interpreted as SQL code.
  3. CFirewalls filter network traffic; SQL injection travels inside normal, allowed web requests, so firewall rules are not the root cause.
  4. DSchema design affects what an attacker can reach after injection, but the flaw itself comes from unsafe handling of input in queries.
T-03

An analyst correlates a critical web application firewall alert for SQL injection with a sequence of HTTP 500 Internal Server Error application logs. What is the most accurate interpretation of these events?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. AServer errors alone do not prove compromise or exfiltration; confirming that would require evidence such as abnormal result sizes, outbound transfers, or database audit records.
  2. BCorrect: the alert shows an attempt was detected, and 500 errors suggest the input broke query execution rather than returning data, though the endpoint still deserves review.
  3. CBoolean blind extraction depends on the application returning normal but differing responses; a run of internal server errors points to failed execution, not quiet data inference.
  4. DA successfully processed query would normally yield ordinary responses; repeated 500 errors indicate the backend could not handle the input as submitted.
T-04

A critical SQL injection is found in a legacy application. The source code is permanently lost, preventing the immediate implementation of parameterized queries. Which interim mitigation strategy provides the BEST defensive response?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. ACorrect: WAF virtual patching blocks known exploit patterns at the edge while least privilege limits what an injected query could reach until code can be rebuilt.
  2. BColumn encryption protects data at rest but does not stop an injected query, and the application usually decrypts data for its own account anyway.
  3. CClient-side JavaScript validation runs in the attacker's browser and is trivially bypassed, so it provides no real protection for the server-side query.
  4. DAn emergency NoSQL migration is a major re-architecture, not an interim fix, and NoSQL databases have their own injection risks.
T-05

A target application suppresses all database error messages. Appending LIMIT 1 to a valid query returns normal content, whereas appending TOP 1 results in a blank page. Which backend database is MOST likely in use?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. AOracle historically used ROWNUM and now uses FETCH FIRST for row limiting, so it would reject LIMIT rather than accept it as the stem describes.
  2. BMicrosoft SQL Server uses TOP for row limiting, so it would have accepted TOP 1 and rejected LIMIT, the opposite of the observed behavior.
  3. CSybase ASE shares its SQL dialect lineage with SQL Server and supports TOP, so it would not explain TOP failing while LIMIT works.
  4. DCorrect: LIMIT is native to MySQL and PostgreSQL while TOP belongs to the SQL Server family, so this behavioral difference fingerprints the backend even without error messages.
T-06

A remediation report claims a SQL injection flaw is fixed because the application now returns an HTTP 403 status. Which critical verification step is missing to definitively confirm the vulnerability is remediated?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. ALowering the CVSS score is a reporting change made after verification, not evidence that the underlying query flaw is actually fixed.
  2. BCorrect: a 403 may only mean a WAF or filter blocked the request, so confirming in backend logs that input is handled as data proves the root cause is gone.
  3. CEscalating the attack against infrastructure goes beyond verifying the fix and likely exceeds the authorized scope of a retest.
  4. DDropping all external traffic would break the application; a remediation check must confirm safe query handling, not total network blocking.
T-07

A legacy application previously leaked database error messages when SQL syntax was invalid, allowing error-based fingerprinting. After a framework update, all errors return a generic "An error occurred" page with HTTP 200 status, but the application still processes user input unsafely. Which adaptation is MOST effective for continued SQLi testing?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. AGeneric error pages only remove one feedback channel; if input is still concatenated into queries, the injection flaw remains and other inference methods can still confirm it.
  2. BA framework update that hides errors is not evidence of input validation; stopping testing on that assumption leaves a known unsafe code path unverified.
  3. CCorrect: when errors are hidden, testers infer behavior from true-versus-false response differences or controlled timing, which shows whether the flaw persists without needing error output.
  4. DUNION-based techniques need query results reflected in the page and matching column structure; relying on them exclusively ignores the blind methods better suited here.
T-08

A development team experiences repeated false positives from WAF SQL injection rules on a legacy PHP application. An operations engineer proposes disabling CRS rule category 942 entirely to eliminate alert noise. Which alternative approach BEST maintains SQLi protection while addressing the false positives?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. ACorrect: observing traffic first, then adding narrow parameter- or endpoint-level exceptions before restoring blocking, removes false positives while keeping the SQLi rule set active.
  2. BDisabling the whole SQL injection rule category removes a key compensating control for a legacy application whose own input handling is already suspect.
  3. CPermanent detection-only mode means attacks are merely logged, so this application loses all WAF blocking for SQL injection rather than getting tuned rules.
  4. DRaising the anomaly threshold globally weakens detection for every attack category and application, trading broad protection for less noise instead of fixing the specific rules.
T-09

An unauthenticated attacker exploits a boolean-based SQL injection to successfully achieve Remote Code Execution on a backend database server. Which CVSS metric configuration best represents this escalated exploit scenario?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. AIn CVSS v3.1 terms, high complexity and high privileges contradict the scenario, since the attacker is unauthenticated and the injection is readily exploitable.
  2. BNo required privileges fits an unauthenticated attacker, but remote code execution on the database server is a severe impact, not none across confidentiality, integrity and availability.
  3. CCorrect: in CVSS v3.1, a reliable injection gives Low attack complexity, an unauthenticated attacker means Privileges Required None, and code execution means High CIA impact.
  4. DLow privileges wrongly implies the attacker needed an account, and CVSS v3.1 impact values are None, Low or High, so a Moderate rating does not exist.
T-10

Which of the following is NOT a typical consequence of a successful SQL injection exploit?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. AUnauthorized access to records is a common SQL injection outcome, since injected queries can read data the application never meant to expose.
  2. BCorrect: SQL injection affects data and logic in the database, not physical hardware, so hardware damage is not a typical consequence.
  3. CAltering or deleting records is a well-known impact when the application's database account has write privileges.
  4. DExposing stored usernames, password hashes or API keys is a frequent SQL injection consequence and often enables further compromise.
T-11

What is the primary objective of an attacker using SQL injection techniques on a web application?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. ACorrect: SQL injection lets an attacker change the queries an application sends to its database, so the usual aims are reading, modifying or deleting data they should not reach.
  2. BSQL injection acts on database queries, not on application source files; changing application code would require a different flaw such as file write or deployment access.
  3. CStorage capacity is an infrastructure setting, and no attacker objective in SQL injection involves giving the target server more resources.
  4. DSchema changes are possible when the database account is overprivileged, but they are a side effect of excessive rights rather than the main goal of the technique.
T-12

During an authorized penetration test, you discover a critical SQL injection flaw in a live production environment. Which action ethically demonstrates the vulnerability's impact to the client without causing unauthorized business disruption?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. APulling real customer records, even a small sample, exposes personal data beyond what is needed to prove the flaw and may breach the rules of engagement.
  2. BCorrect: reading harmless metadata such as the database version or current user proves the injection executes while avoiding sensitive data and any production impact.
  3. CChanging production data, even briefly, risks integrity and availability problems and normally requires explicit written permission that the stem does not mention.
  4. DCopying a full user table creates a large store of sensitive data the tester must then protect, far exceeding what is needed to demonstrate impact.
T-13

A function strips single quotes from input before appending it to a database query. Under which condition does this defense fail to prevent SQL injection?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. AOutput encoding protects against cross-site scripting when data is displayed; it has no effect on how input is interpreted inside a database query.
  2. BCorrect: in a numeric context no quote is needed to break out of the value, so stripping quotes fails; parameterized queries are the reliable fix.
  3. CLength limits can make some injections harder, but they do not cause quote stripping to fail, and short injections can still fit.
  4. DStrong database access controls limit the damage of a successful injection, yet they are not a condition under which the quote filter is bypassed.
T-14

An assessment reveals multiple SQL injection vulnerabilities. Which remediation approach optimally prioritizes risk reduction for a critical authentication endpoint vulnerable to a union-based attack?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. ATime-based blind flaws behind authentication are harder to reach and slower to exploit, so they rank below an unauthenticated login endpoint in remediation order.
  2. BLeast privilege limits the damage of any injection and is worth doing, but it does not remove the flaw letting attackers bypass or abuse the login query.
  3. CCorrect: the login endpoint is exposed to everyone and union-based injection returns data directly, so fixing it at the root with parameterized queries reduces the most risk first.
  4. DOutput encoding prevents cross-site scripting in rendered pages; it does nothing to stop input from changing the structure of a SQL query.
T-15

You are testing a web application's login page for SQL injection vulnerabilities. Which tool would you primarily use to automate and perform this test?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. AJoomScan is a vulnerability scanner specialized for Joomla content management sites, not a general tool for testing a login form for SQL injection.
  2. BWireshark captures and analyzes network packets; it can show the traffic but does not generate or automate injection tests against an application.
  3. CCorrect: SQLMap is an open-source tool dedicated to detecting and confirming SQL injection flaws, and defenders see its noisy probing patterns in WAF and server logs.
  4. DAcunetix is a broad commercial web vulnerability scanner that includes SQL injection checks, but the tool dedicated to automating SQL injection testing is SQLMap.
T-16

A code review reveals that a web application uses parameterized queries for all user input, eliminating SQL injection in query construction. However, the database account used by the application has `db_owner` privileges. Which residual risk remains MOST significant?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. ACorrect: parameterization closes the injection path, but a db_owner account means any other flaw reaching the database gets full control, violating least privilege.
  2. BParameterized calls also protect stored procedure parameters, unless the procedure itself builds dynamic SQL, which the scenario does not describe.
  3. CCross-site scripting runs in the victim's browser and cannot change server-side queries that are already parameterized.
  4. DOperating system command injection needs a separate flaw and specific database features; the most significant residual risk is the excessive privilege itself.
T-17

In the context of an SQL injection, which command allows adding new rows of data to a table?

Make the call. Every option has a note waiting here.

Notes on all 4 options
  1. AAPPEND is not a SQL data manipulation command; adding rows to a table is done with a different standard statement.
  2. BCorrect: INSERT adds new rows to a table, and an injectable INSERT could plant unauthorized records such as rogue accounts, which is why least privilege matters.
  3. CCREATE defines new database objects such as tables, views or indexes; it adds structure rather than rows of data to an existing table.
  4. DADD appears only as part of ALTER TABLE to add columns or constraints; it is not a standalone command for inserting data rows.

Two loose ends

Is the CEH view of injection out of date against OWASP?

The ranking moved; the defense did not. The v13 course outline names the OWASP Top 10 2021 edition, and the current OWASP Top 10:2025 lists Injection as A05 (both checked Oct 11, 2026). Parameterized queries are the primary fix under either edition.

Does an ORM rule out SQL injection?

Not by itself. ORMs bind parameters by default, but most also offer raw-query features, and a filter assembled from strings through one of those is a concatenated query again.

Sources