SQL injection succeeds when attacker input changes the structure of a database query, and the query string is the one place where that change is fully visible. MITRE D3FEND names the countermeasure Database Query String Analysis (D3-DQSA) and defines it as "Analyzing database queries to detect SQL Injection." It belongs to the Detect tactic as a child of Process Analysis (D3-PA), and its single digital artefact is the Database Query, which D3FEND defines as a specific query expressed in SQL, SPARQL or a similar language against a database. This card covers what D3-DQSA inspects, the one ATT&CK technique D3FEND relates it to, where the analysis can run, how to prove it works and where it falls short. It is for detection engineers, application security teams and database administrators; prevention through parameterised queries is covered in the SQL Injection Prevention Guide and is not repeated here.
Key takeaways
- It analyses the query, not the request. D3-DQSA looks at the SQL that actually reaches the database, after the application has built it, which is where injected syntax becomes unambiguous.
- Three analysis methods. D3FEND lists detecting specific administrative SQL commands, anomalous command sequences compared with a statistical baseline, and anomalous commands for a given user role.
- One inferred ATT&CK link. D3FEND relates D3-DQSA to Exploit Public-Facing Application (T1190), because that technique injects a Database Query, the artefact D3-DQSA analyses.
- Detection, not a substitute for safe code. OWASP's primary defences are parameterised queries and allow-list validation; query analysis catches what slips through and shows where the vulnerable code is.
- Blocking has a cost. D3FEND's own considerations warn that sanitising queries in flight can alter data in unwanted ways or break application functionality, so start in alert-only mode.
D3-DQSA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-DQSA (d3f:DatabaseQueryStringAnalysis) |
| Tactic | Detect |
| Parent technique | Process Analysis (D3-PA) |
| Digital artefact | Database Query (D3FEND relation: analyzes Database Query) |
| Attack pattern named in the definition | SQL Injection (CAPEC-66); Blind SQL Injection (CAPEC-7) is a common variant |
| Collection points named by D3FEND | Software hooks on database query function calls; interception or collection of network traffic |
| D3FEND reference | Cylance Inc patent US20120117644A1, "System and method for internet security" |
| Typical data sources | Database audit logs with statement text, database threat detection alerts, in-application query hooks, database activity monitoring sensors |
| Main limitation | Only sees queries; injection into NoSQL stores, ORMs with raw fragments and stored procedures needs matching coverage |
How it works
D3FEND's description has two steps: capture the query string, then analyse it. Capture happens either through software hooks that intercept function calls related to database query operations, or by intercepting or collecting network traffic between the application and the database. Analysis then uses one or more of three methods.
- Administrative command detection: flag statements an application should never issue, such as privilege changes, server configuration calls or operating system command execution. The D3FEND reference gives the example of a rule that rejects any query that is excessively long or contains a string such as xp_cmdshell.
- Statistical baselining: learn the normal shapes and sequences of queries and alert on new ones. A web application tends to issue a small, stable set of query templates, so a never-seen template, an unusual UNION or a sudden burst of schema queries stands out.
- Role-based anomaly: compare each command with what the issuing database role normally does. An application login that only ever reads and writes order rows should not be enumerating system catalogues.
The Cylance patent cited by D3FEND adds a precise variant: one hook persists the incoming web request, a second hook intercepts the query the request produced, and the two are compared character by character. If the request supplied characters that changed the query's syntax, the query is flagged before execution. This request-to-query correlation is the same idea used by runtime application self-protection (RASP) agents, and it is the most accurate form of D3-DQSA because it knows which part of the query came from the user.
Where identity fits
The role-based method depends on database identities being distinct. When every application, batch job and report tool connects with one shared login, there is no "normal for this role" to compare against. Giving each application its own database login with least privilege, which OWASP lists as an additional defence, also makes D3-DQSA sharper: a reporting account issuing DELETE statements is an immediate signal. These application logins are non-human identities and belong in the same inventory as other service accounts; see How to audit SQL Server service accounts and logins and the Service Account Behavioural Baselining Guide.
ATT&CK technique D3FEND relates to D3-DQSA
D3FEND lists one related technique, and the relationship is inferred: D3-DQSA analyses Database Query, and ATT&CK's Exploit Public-Facing Application is modelled as injecting a Database Query. D3FEND labels such relations "inferred and experimental" (D3FEND 1.6.0, checked November 2026). The ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | Tactic | D3FEND relation (inferred via artefact) | What query analysis catches |
|---|---|---|---|---|
| T1190 | Exploit Public-Facing Application | Initial Access | Same artefact: T1190 injects Database Query | Injected syntax, tautologies, stacked statements and UNION-based extraction reaching the database from an internet-facing application |
In NHI Mgmt Group's view (not a D3FEND mapping), the same telemetry also helps with activity that follows a successful injection, such as bulk reads under Data from Information Repositories: Databases (T1213.006) or persistence through SQL Stored Procedures (T1505.001). Treat that as a bonus, not coverage. For the attack itself see the T1190 Exploit Public-Facing Application Defensive Guide.
Where it is implemented
| Implementation class | Where it sees the query | Strengths | Watch out for |
|---|---|---|---|
| In-application hooks and RASP agents | Inside the application runtime, at the database driver call | Can correlate the user input with the final query, as in the D3FEND reference; low false positives | Per-language agents, performance overhead, needs application team ownership |
| Database native auditing | Inside the database engine, written to audit logs. The PostgreSQL pgAudit extension, for example, logs statement classes READ, WRITE, FUNCTION, ROLE, DDL and MISC with the statement text | Sees every statement, including dynamic SQL inside functions and DO blocks | Log volume; pgAudit documents that logging is best effort and that superuser activity cannot be reliably audited |
| Cloud database threat detection | Provider-side analysis of database activity by the cloud platform, which can raise alerts for likely SQL injection attempts and for application code that generates vulnerable statements | No agents for managed databases; alerts flow into the cloud security console | Thresholds and models are not documented; coverage differs by deployment type |
| Database activity monitoring (DAM) sensors | Network tap or host agent between application and database | Central policy across many engines; role and template baselining | Encrypted connections need host agents or key access; extra infrastructure |
| Web application firewalls (adjacent, not D3-DQSA) | The HTTP request before the application builds the query. Examples: the AWS WAF AWSManagedRulesSQLiRuleSet rule group (rules such as SQLi_QUERYARGUMENTS and SQLi_BODY) and the OWASP Core Rule Set with paranoia levels 1 to 4 | Blocks common payloads at the edge | Sees input, not the resulting query; body inspection limits (AWS documents 8 KB for Application Load Balancer); higher CRS paranoia levels need tuning |
A WAF is listed because teams often assume it covers this technique. It is the complementary edge control: it never sees the query string D3FEND defines as the artefact. The Database Activity Monitoring buyer's guide covers DAM selection, and engine-specific audit settings are in the PostgreSQL Security Guide, MySQL Security Guide and Microsoft SQL Server Security Guide.
Implementation steps
- Choose the databases. Start with databases behind internet-facing applications, since that is the T1190 path. Record each application, its database logins and the collection point you will use.
- Separate the logins. Give each application and job its own database login. Without this, role-based analysis has nothing to compare.
- Turn on capture with statement text. Enable native auditing scoped to application logins (for pgAudit, object audit logging or class exclusions keep volume down), or deploy the hook, agent or DAM sensor. Size log storage and test performance first, as the pgAudit documentation advises.
- Write the first rules. Alert on administrative and system commands from application logins, on syntax errors from application logins (a classic sign of injection probing), on access to system catalogue tables, and on stacked or commented statements.
- Baseline for two to four weeks. Build the set of query templates per application login. New templates after a release are expected; new templates without a release are not. The duration is an example, not a standard.
- Stay in alert-only mode. D3FEND warns that sanitising queries can alter data or break functionality. Move a specific rule to blocking only when it has produced no benign hits over a full business cycle, and keep a switch to return it to alert-only.
- Route findings to developers. Each confirmed alert points at a query built from user input. Fix the code with parameter binding, then keep the rule as a regression check.
How to verify it works
- Controlled test cases: in a test environment, or in production under an authorised testing agreement, send benign injection test strings (for example an unbalanced quote or an always-true condition) to a known-vulnerable test endpoint and confirm the alert fires with the application login, the query text and the source request.
- Role anomaly test: run an administrative or catalogue query using the application login from an approved test host and confirm the role-based rule fires.
- Coverage check: list every database behind an internet-facing application and confirm capture is on and logs are arriving. A missing audit log stream disables the control silently.
- Scanner correlation: when dynamic application security testing runs, compare its findings with D3-DQSA alerts. Injection the scanner found that produced no alert is a detection gap.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Internet-facing application databases with query capture on | 100% | The T1190 path is the priority |
| Applications using a dedicated database login | Rising to 100% | Role-based analysis depends on it |
| Controlled injection tests detected | 100% per quarter | Proves capture and rules end to end |
| Confirmed alerts closed by a code fix | Tracked per quarter | Detection should lead to removal of the vulnerable query |
| Benign alerts per application per week after baselining | Falling, close to zero | Shows the baseline is accurate |
Limits, bypasses and failure patterns
- Obfuscated payloads: string concatenation, casting and base conversion defeat simple pattern matching. Microsoft's own alert list describes obfuscation used to evade regex detection, which is why baselining and request-to-query correlation matter.
- Injection that looks like normal SQL: blind and time-based injection can produce queries that are syntactically valid and close to the baseline. Low-and-slow probing may stay under statistical thresholds.
- Shared logins: one login for every application hides role anomalies and makes alerts hard to trace to a codebase.
- Superuser and DBA blind spots: pgAudit documents that superuser activity cannot be reliably audited; an attacker who reaches a privileged login can turn auditing off, which is Disable or Modify Tools territory (T1685 Disable or Modify Tools Defensive Guide).
- Non-SQL stores: D3FEND's artefact includes SPARQL and similar languages, but most tooling is SQL only. Document stores need their own approach; see the NoSQL Injection Prevention Guide.
- Treating detection as the fix: an injection alert that is tuned out instead of fixed leaves the vulnerable code in place. OWASP is clear that parameter binding is the primary defence.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-10 Information Input Validation | The preventive control whose failure D3-DQSA detects |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring; AU-6 Audit Record Review, Analysis, and Reporting | Monitoring and review of database audit records |
| NIST CSF 2.0 | DE.CM-09, DE.AE-02 | Monitoring software and runtime environments; analysing adverse events |
| MITRE CAPEC | CAPEC-66 SQL Injection; CAPEC-7 Blind SQL Injection | The attack patterns D3-DQSA targets |
| MITRE D3FEND | D3-PA, D3-DQSA | Parent and technique |
Related countermeasures
- Other Process Analysis children: D3-FAPA File Access Pattern Analysis applies the same "watch what the process touches" idea to files.
- Resource Access Pattern Analysis: D3-RAPA Resource Access Pattern Analysis looks at which resources an identity reaches, a useful second view of a compromised application login.
- Restore Database (D3-RD): the recovery step when injection was used to change or destroy data.
- The wider model: see the MITRE D3FEND Guide for how Detect techniques fit together.
Practitioner checklist
- Enable query capture with statement text for every database behind an internet-facing application.
- Give each application and job its own least-privilege database login.
- Alert on administrative commands, system catalogue access and syntax errors from application logins.
- Baseline query templates per login and alert on new templates outside releases.
- Keep rules in alert-only mode until they are proven free of benign hits.
- Run controlled injection tests each quarter and record the result.
- Send every confirmed alert to the owning development team for a parameter-binding fix.
- Do not count a WAF as query analysis; run both.
- Restrict and separately monitor superuser and DBA logins.
Standards and references
- MITRE D3FEND: Database Query String Analysis (D3-DQSA)
- MITRE CAPEC: CAPEC-66 SQL Injection
- MITRE ATT&CK: T1190 Exploit Public-Facing Application
- OWASP: SQL Injection Prevention Cheat Sheet
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- pgAudit: PostgreSQL Audit Extension documentation
- AWS: WAF use-case specific rule groups (SQL database)
- OWASP Core Rule Set: Paranoia levels
- Google Patents: US20120117644A1 System and method for internet security
Related NHI Mgmt Group resources: SQL Injection Prevention Guide · Database Security Guide · Database Activity Monitoring · T1190 Exploit Public-Facing Application Defensive Guide · MITRE D3FEND Guide