Special Element Injection

This is CWE-74, the true umbrella parent that every named injection class, SQL injection, command injection, LDAP injection, XPath injection, XML injection, ultimately falls under. The name describes the mechanism shared by all of them: user input crosses from one "plane," the plain data it was supposed to be, into another plane, a query language, a shell, a directory-lookup syntax, where certain characters carry structural meaning instead of being treated as inert text. Reports land in this general bucket rather than one of the specific named children when the exact downstream interpreter isn't immediately obvious from the report, or when the injection targets a less common interpreter (a template engine, a regular expression engine, a custom domain-specific query syntax) that doesn't have its own well-established name.

• Directory services using LDAP queries built from user input (login forms, user search)
• XPath queries built from user input in XML-backed data stores
• Any less common structured-query interpreter (a custom filter syntax, a template engine, a rules engine) that accepts user input directly into its query language

• Identify what downstream interpreter a given input actually reaches (LDAP, XPath, a template engine, a custom query syntax) before choosing a payload, since the effective injection characters are entirely specific to that interpreter's own syntax
• For LDAP specifically, inject filter metacharacters (*, (, ), \) to alter the structure of a search filter and potentially match or bypass more than the intended query
• For XPath, inject query-altering syntax (' or '1'='1) analogous to classic SQL injection but targeting XPath's own expression syntax

• *)(uid=*))(|(uid=* for LDAP filter injection, designed to short-circuit a search filter into matching every entry
• ' or '1'='1 and its XPath-specific variants for XPath injection
• Interpreter-specific structural characters for whatever the target's downstream query syntax turns out to be, once identified

The first step is always identifying which downstream interpreter a given input actually reaches, since the meaningful special characters and effective payloads are entirely specific to that interpreter. Once identified, apply the standard testing approach for that specific class directly: LDAP filter metacharacters for a directory lookup, XPath-injection syntax for an XML-backed query, or the specific structural syntax of whatever custom interpreter is in play.

Tip: Testing tools that run these checks in parallel across every discovered endpoint can cut the time required substantially compared to fully manual testing, as long as they confirm findings with more than one signal to keep the false-positive rate down.

As with any injection class, a response difference between an injected and a clean payload isn't sufficient on its own; confirmation requires demonstrating that the injected structural characters actually altered the query's logic, ideally by extracting or matching data the clean baseline didn't.

Manual Testing Methodology

Here is a systematic approach to identifying Special Element Injection vulnerabilities in a target application.

Before testing, map all input vectors that could be affected. Identify parameters, headers, cookies, and request bodies that interact with the vulnerable component. A proxy such as Burp Suite or OWASP ZAP, paired with normal browsing of the target, is usually enough to build this list.

Send a legitimate request and record the normal response: status code, content length, response time, and any identifying tokens. This baseline matters because it's what you'll compare later responses against once payloads are involved.

Inject test payloads into each identified input vector one at a time. Start with benign detection payloads before escalating to anything that could actually trigger the vulnerability. For Special Element Injection specifically, submit LDAP-filter metacharacters (*, (, ), &, |) or XML structural characters (<, >, &, a crafted closing tag) into every parameter that feeds into a directory query or an XML document, testing both authentication-bypass-style payloads and structural injection.

Compare the response against your baseline, looking specifically for authentication bypassing unexpectedly, broader directory results than the query should return, or injected elements/attributes appearing in how the application subsequently processes the document.

Once a potential vulnerability is detected, confirm it with at least a few independent test cases to rule out coincidence. Document the exact request and response as proof. For Special Element Injection, a confirmed finding typically means showing that attacker-controlled input changes the application's behavior in a way that matters for security, not just that a payload was reflected somewhere harmless.

Real-World Impact

LDAP injection, XML injection, and related structured-syntax injection classes share the same shape as SQL injection but target a different query or document language: user input gets concatenated into an LDAP filter, an XML document, or another structured format without being escaped for that format's special characters, letting an attacker alter the structure the receiving parser sees rather than just its data.

LDAP injection specifically can let an attacker bypass authentication filters entirely (by injecting a filter that always evaluates true) or enumerate directory contents — usernames, group memberships, organizational structure — that should have required legitimate query permissions to see. XML injection can let an attacker add, modify, or spoof elements the application trusts, which is especially serious when those elements carry authorization-relevant data.

Both are less frequently reported than SQL or command injection simply because LDAP and raw XML query construction are less common than SQL in modern applications, but where they do exist, the exploitation pattern and severity are directly comparable.

Prevention and Secure Coding

Preventing Special Element Injection takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Use the platform's parameterized/escaping API for the target syntax. Most LDAP and XML libraries provide a proper escaping function or parameterized filter-building API — use it instead of string concatenation, the same discipline as parameterized SQL.

Allowlist validate before it ever reaches the query. Restrict input feeding into a filter or document structure to an expected character set and length before it's used at all.

Least-privilege service accounts for the underlying directory or document store. An LDAP bind account or XML-processing service account scoped to only what it needs limits what a successful injection can actually reach.

Treat structural characters as forbidden, not something to sanitize away. Reject input containing syntax-significant characters for the target format (()&| for LDAP filters, <>& for raw XML construction) rather than trying to strip or escape them ad hoc.