Quick answer: LDAP injection is the alteration of filter logic when an application adds user input to an LDAP (directory service, for example Active Directory) query filter without sanitization. Most enterprise applications look a user up in the directory at login; the filter is built like (uid=entered_name). If the attacker puts special characters such as * or *)(uid=*))(|(uid=* into the username, the filter matches every user and authentication can be bypassed, or unauthorized information can be pulled from the directory. Special characters carry meaning in LDAP: (, ), *, \, &, |, =, NUL. The fix is to sanitize input with LDAP escaping rules (escape every special character), validate input against the expected format, and where possible use a parameterized/framework-managed query.

LDAP injection is a less-discussed but high-impact flaw in enterprise environments, because it touches the central identity infrastructure (Active Directory, enterprise directory) directly. It is not as well known as SQL and NoSQL injection, so developers often skip escaping special characters. This guide explains why the LDAP filter syntax is open to attack, the most common bypass examples, how it is detected, and the correct defense.

How an LDAP filter works and why it is vulnerable

LDAP queries use a special filter syntax. For example, to find a user you write (uid=ahmet), and to combine two conditions (&(uid=ahmet)(password=123)). Here & means "and," | means "or," * means "anything" (wildcard), and parentheses group conditions. These characters are the control characters of the filter.

The problem appears when the application adds user input directly into this filter. If the login filter is built as (&(uid=INPUT)(password=INPUT)) and the attacker types * into the username field, the filter becomes (&(uid=*)(password=...)) and uid=* matches all users. More powerfully, the attacker can break the filter structure by placing a payload like admin)(&) into the username and neutralize the password condition. This is the LDAP equivalent of the ' OR '1'='1 pattern in SQL injection: the root cause is the same, the input is interpreted as query structure instead of data.

The most common attack forms

Technique Payload example Impact
Wildcard match username * Matching any user
Breaking the filter structure *)(uid=*))(|(uid=* Neutralizing the password condition
Always-true condition something like admin)(&) Authentication bypass
Blind information extraction trying attributes one by one Exfiltrating data from the directory
Querying authorization attributes manipulating a group/role filter Leaking authorization information

Blind extraction resembles the $regex attack in NoSQL: even if the attacker cannot see an attribute's value directly, they can extract it by trying the filter character by character (checking whether the response changes). Because directory services hold sensitive attributes such as user, group, role, email and phone, a successful LDAP injection leads to serious information disclosure. We separately cover internal-network attack techniques against Active Directory in our Active Directory internal network penetration test article.

How it is detected

Detection begins by testing whether LDAP special characters affect the filter. The pentester sends characters such as *, (, ), \, &, | and payloads like *)(uid=* into a login or search field and sees whether the behavior changes: if the login unexpectedly succeeds, the search returns more results, or a different error appears, the flaw signals itself. All results returning from a single * is a classic proof.

These tests are done by intercepting a legitimate request and modifying the input; the flow we describe in our Burp Suite guide applies here too. For the general logic of the injection class, see our OWASP Top 10 web application security article; LDAP injection is the directory-service application of the same A03 Injection item.

The correct defense: escaping, validation, parameterized query

The fix for LDAP injection is to guarantee that user input determines only the searched value, not the filter structure:

  • LDAP special-character escaping. Before putting input into the filter, sanitize it according to LDAP escaping rules. The RFC-defined escaping is: * to \2a, ( to \28, ) to \29, \ to \5c, NUL to \00. Mature LDAP libraries offer an escape/filter-builder function that does this; use it instead of manual concatenation.
  • Input validation. For fields like username, enforce the expected format (for example only letters, digits, a limited character set); filter out input containing special characters before it even reaches the filter.
  • Framework/parameterized query. Where possible, use the library's safe filter-building API instead of inserting input into the filter text as a string; this makes escaping automatic and consistent.
  • Connect with least privilege. The service account the application uses to connect to the directory should read only the attributes it needs, so that even a successful injection leaks limited information. Do authentication as search-then-bind, and do not put the input into the same filter as the password directly.
  • Generalize error messages. Detailed LDAP errors give away the filter structure to the attacker; return a generic message to the client and write the detail to the server log.

We cover the general principles of enterprise identity management in our IAM identity and access management article.

The KAOS and DSET approach

At DSET we specifically test the login and directory-search endpoints of enterprise applications against LDAP injection, because this flaw touches central identity infrastructure and therefore has large impact, and because it is little known it is often left in the field. In our tests we stress login and search fields with LDAP special characters and filter-breaking payloads, and we do not merely detect the flaw but verify it by proving the bypassed authentication or the exfiltrated directory information. Our KAOS tool flags patterns that concatenate user input into an LDAP filter without escaping, but it ties the final verdict to evidence. To have your Active Directory or LDAP-integrated application tested, contact DSET and reach our team at Ankara Hacettepe Teknokent.

Frequently asked questions

What is the difference between LDAP injection and SQL injection? The root cause is the same: user input being interpreted as query structure instead of data. The difference is in the syntax. SQL uses quotes and keywords, while LDAP uses filter control characters (*, (, ), &, |). The defense is similar too: escape/validate the input and separate structure from value. Because LDAP injection touches the enterprise identity infrastructure, its impact is often more critical.

Is entering just * enough to bypass login? It depends on how the application builds the filter. In some weak designs, putting * in the username can lead to matching all users and logging in with the first account. More commonly, payloads that break the filter structure (like *)(uid=*) neutralize the password condition. In both cases the fix is to escape special characters and use the search-then-bind flow.

I use a mature LDAP library, is there still a risk? If you use the library's safe filter-building API, the risk is largely closed. The risk arises when the developer puts input into the filter with manual string concatenation. So the real matter is not the presence of a library but its correct use: use the escape function or the parameterized filter API, and never do raw concatenation.

Sources