1. Home
  2. CWE Database
  3. CWE-943
Class · High

CWE-943: Improper Neutralization of Special Elements in Data Query Logic

The product generates a query intended to access or manipulate data in a data store such as a database, but it does not neutralize or incorrectly neutralizes special elements that can modify the inten...

CWE-943 · Class Level ·5 CVEs

Description

The product generates a query intended to access or manipulate data in a data store such as a database, but it does not neutralize or incorrectly neutralizes special elements that can modify the intended logic of the query.

Depending on the capabilities of the query language, an attacker could inject additional logic into the query to: The ability to execute additional commands or change which entities are returned has obvious risks. But when the product logic depends on the order or number of entities, this can also lead to vulnerabilities. For example, if the query expects to return only one entity that specifies an administrative user, but an attacker can change which entities are returned, this could cause the logic to return information for a regular user and incorrectly assume that the user has administrative privileges. While this weakness is most commonly associated with SQL injection, there are many other query languages that are also subject to injection attacks, including HTSQL, LDAP, DQL, XQuery, Xpath, and "NoSQL" languages.

Potential Impact

Confidentiality, Integrity, Availability, Access Control

Bypass Protection Mechanism, Read Application Data, Modify Application Data, Varies by Context

Demonstrative Examples

The following code dynamically constructs and executes a SQL query that searches for items matching a specified name. The query restricts the items displayed to those where owner matches the user name of the currently-authenticated user.
Bad
...string userName = ctx.getAuthenticatedUserName();string query = "SELECT * FROM items WHERE owner = '" + userName + "' AND itemname = '" + ItemName.Text + "'";sda = new SqlDataAdapter(query, conn);DataTable dt = new DataTable();sda.Fill(dt);...
The query that this code intends to execute follows:
Informative
SELECT * FROM items WHERE owner = <userName> AND itemname = <itemName>;
However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string:
Attack
name' OR 'a'='a
for itemName, then the query becomes the following:
Attack
SELECT * FROM items WHERE owner = 'wiley' AND itemname = 'name' OR 'a'='a';
The addition of the:
Attack
OR 'a'='a
condition causes the WHERE clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:
Attack
SELECT * FROM items;
This simplification of the query allows the attacker to bypass the requirement that the query only return items owned by the authenticated user; the query now returns all entries stored in the items table, regardless of their specified owner.
The code below constructs an LDAP query using user input address data:
Bad
context = new InitialDirContext(env);String searchFilter = "StreetAddress=" + address;NamingEnumeration answer = context.search(searchBase, searchFilter, searchCtls);
Because the code fails to neutralize the address string used to construct the query, an attacker can supply an address that includes additional LDAP queries.
Consider the following simple XML document that stores authentication information and a snippet of Java code that uses XPath query to retrieve authentication information:
Informative
<users><user><login>john</login><password>abracadabra</password><home_dir>/home/john</home_dir></user><user><login>cbc</login><password>1mgr8</password><home_dir>/home/cbc</home_dir></user></users>
The Java code used to retrieve the home directory based on the provided credentials is:
Bad
XPath xpath = XPathFactory.newInstance().newXPath();XPathExpression xlogin = xpath.compile("//users/user[login/text()='" + login.getUserName() + "' and password/text() = '" + login.getPassword() + "']/home_dir/text()");Document d = DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(new File("db.xml"));String homedir = xlogin.evaluate(d);
Assume that user "john" wishes to leverage XPath Injection and login without a valid password. By providing a username "john" and password "' or ''='" the XPath expression now becomes
Attack
//users/user[login/text()='john' or ''='' and password/text() = '' or ''='']/home_dir/text()
This lets user "john" login without a valid password, thus bypassing authentication.

Detection Methods

  • Automated Static Analysis High — Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then sea

Real-World CVE Examples

CVE IDDescription
CVE-2024-50672NoSQL injection in product for building eLearning courses allows password resets using a query processed by the Mongoose find function
CVE-2021-20736NoSQL injection in team collaboration product
CVE-2020-35666NoSQL injection in a PaaS platform using a MongoDB operator
CVE-2014-2503Injection using Documentum Query Language (DQL)
CVE-2014-2508Injection using Documentum Query Language (DQL)

CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')

The product constructs all or part of a command, data structure, or record using externally-influenced input from an ups...

Frequently Asked Questions

What is CWE-943?

CWE-943 (Improper Neutralization of Special Elements in Data Query Logic) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Class-level weakness. The product generates a query intended to access or manipulate data in a data store such as a database, but it does not neutralize or incorrectly neutralizes special elements that can modify the inten...

How can CWE-943 be exploited?

Attackers can exploit CWE-943 (Improper Neutralization of Special Elements in Data Query Logic) to bypass protection mechanism, read application data, modify application data, varies by context. This weakness is typically introduced during the Implementation phase of software development.

How do I prevent CWE-943?

Follow secure coding practices, conduct code reviews, and use automated security testing tools (SAST/DAST) to detect this weakness early in the development lifecycle.

What is the severity of CWE-943?

CWE-943 is classified as a Class-level weakness (High abstraction). It has been observed in 5 real-world CVEs.