LDAP Injection

Overview

LDAP injection happens when attacker-controlled input is concatenated into LDAP filters without proper escaping. The impact is often authentication bypass, user enumeration, or unauthorized access to directory data. These notes cover LDAP structure, filter syntax, common injection patterns, wildcard and tautology abuse, and blind LDAP extraction techniques.

What LDAP Is

LDAP is a directory access protocol used to store and query structured identity and directory information. It is common in environments such as Microsoft Active Directory and OpenLDAP.

Entries are organized hierarchically and represented as objects with attributes. This makes LDAP especially common in authentication, user management, group membership, and enterprise identity workflows.

Directory Structure

LDAP directories are tree-based. Important concepts include:

• DN (Distinguished Name): the full path to an entry, such as cn=John Doe,ou=people,dc=example,dc=com.
• RDN (Relative Distinguished Name): one level in the hierarchy, such as cn=John Doe.
• Attributes: properties such as mail=john@example.com.
• OU: organizational units used to group entries.

LDAP Filters

LDAP search queries are built from a base DN, a scope, a filter, and requested attributes. The filter is the key part from an injection perspective.

Simple Match

(cn=John Doe)

Wildcard Match

(cn=J*)

Logical Filter

(&(objectClass=user)(|(cn=John*)(cn=Jane*)))

The logical operators are especially important:

• & for AND
• | for OR
• ! for NOT
• * as a wildcard

How LDAP Injection Happens

LDAP injection is conceptually similar to SQL injection. The vulnerable application takes user input, concatenates it into an LDAP filter, and sends the final query to the directory server. If the input is not escaped correctly, the attacker can alter the intended logic.

Typical outcomes include:

• authentication bypass,
• directory enumeration,
• unauthorized access to sensitive user data,
• manipulation of the search result set.

Vulnerable Authentication Pattern

A classic example is an application that builds its LDAP authentication filter directly from POST parameters:

$username = $_POST['username'];
$password = $_POST['password'];

$filter = "(&(uid=$username)(userPassword=$password))";
$search_result = ldap_search($ldap_conn, $ldap_dn, $filter);

If $username or $password are not escaped, the attacker can inject LDAP filter syntax instead of a literal value.

Wildcard Injection

The wildcard * matches any sequence of characters. If the application accepts it unchecked inside an authentication filter, it may match any existing value.

Injected input:

username=*&password=*

Resulting filter:

(&(uid=*)(userPassword=*))

That can match any user with a uid and any user with a userPassword attribute, depending on how the application interprets the result set.

Tautology-Based Injection

LDAP injection can also abuse logical operators to create conditions that are always true.

Suppose attacker input reshapes the filter like this:

(&(uid=*)(|(&)(userPassword=pwd)))

The expression (&) is effectively treated as a trivially true condition in this context, so the OR branch becomes true regardless of whether the submitted password is valid. This can bypass the intended password check.

Targeting Specific Users

Using just * may return the first matching user, but wildcard-style injection can often be tuned. For example, using f* as the username forces the filter toward entries whose uid begins with f.

This turns a simple auth bypass into a way to steer which account is selected by the application.

Blind LDAP Injection

Blind LDAP injection appears when the application does not return full query results but still behaves differently depending on whether the filter matches. The attacker then infers information from success, failure, redirect differences, or wording changes in the response.

Example vulnerable pattern:

$filter = "(&(uid=$username)(userPassword=$password))";
$search_result = ldap_search($ldap_conn, $ldap_dn, $filter);

if ($entries['count'] > 0) {
    if ($entry['uid'][0] === $_POST['username']) {
        $message = "Welcome, " . $entry['cn'][0] . "!\n";
    } else {
        $message = "Something is wrong in your password.\n";
    }
}

Those subtle differences are enough to leak information one character at a time.

Boolean-Style Blind Extraction

An attacker can inject partial username conditions and watch whether the application behaves as if a matching entry exists.

Example payload structure:

a*)(|(&

URL-encoded inside a request, that can reshape the filter into something like:

(&(uid=a*)(|(&)(userPassword=pwd)))

If the application returns a different message, the attacker learns that at least one username beginning with a exists. Then they move to ab*, ac*, and so on until the full identifier is recovered.

Automation

Blind extraction is repetitive, so it is a good candidate for scripting. A loop can iterate through a candidate character set, submit payloads, and watch for the response indicator that means “prefix exists”.

Typical Python approach:

• build a character set,
• append one candidate character at a time to the known prefix,
• submit the crafted payload,
• inspect the response for the success condition,
• repeat until no more characters match.

Testing Approach

• Look for login, search, or user lookup flows backed by LDAP.
• Identify where the application reflects different outcomes for matching versus non-matching filters.
• Test wildcard behavior first, since * is often enough to reveal weak filter handling.
• Probe logical operator injection if the filter structure appears directly concatenated.
• For blind cases, use small prefix tests and watch for wording, timing, or redirect differences.

Mitigation

• Never concatenate raw user input into LDAP filters.
• Use proper LDAP escaping for special characters such as *, (, ), \, and null bytes.
• Keep authentication logic separate from untrusted filter construction.
• Reduce error detail and avoid response differences that expose directory behavior unnecessarily.
• Validate input format strictly before using it in directory operations.

Key Takeaways

• LDAP injection is another case of query logic being rewritten by attacker input.
• Wildcards and logical operators are the main building blocks of LDAP auth bypass.
• Blind LDAP injection can leak usernames or other identifiers through response differences alone.
• Escaping LDAP special characters and avoiding direct filter concatenation are the core defenses.
• Authentication filters deserve the same suspicion and rigor as SQL-backed login code.