What is LDAP Injection?

LDAP injection is an injection vulnerability in applications that query a directory service. If user input is inserted directly into an LDAP filter or distinguished name, special characters can change the meaning of the query. Attackers may bypass a login, enumerate directory entries or access information outside the intended scope.

The underlying mistake resembles SQL injection, but LDAP has its own syntax and escaping rules. A filter used for searching must also be handled differently from a distinguished name. Reusing a generic escape function is therefore not necessarily safe.

How can LDAP injection be prevented?

• - Use a library that safely constructs LDAP filters and distinguished names.
• - Escape values for the exact LDAP context and validate them against a narrow expected format.
• - Bind to the directory with a dedicated, minimally privileged service account.
• - Avoid revealing whether individual directory attributes or accounts exist.

Code example: constructing an LDAP filter safely

Vulnerable:

$username = $_POST['username'];
$filter = "(&(objectClass=person)(uid=$username))";
$result = ldap_search($ldap, $baseDn, $filter);

Safe in filter context:

$username = $_POST['username'];
if (!preg_match('/\A[a-zA-Z0-9._-]{1,64}\z/', $username)) {
    throw new InvalidArgumentException('Invalid username');
}

$safeUsername = ldap_escape($username, '', LDAP_ESCAPE_FILTER);
$filter = "(&(objectClass=person)(uid=$safeUsername))";
$result = ldap_search($ldap, $baseDn, $filter);

A distinguished name would require LDAP_ESCAPE_DN instead. Validation limits the business format; context-specific escaping protects LDAP syntax.

Where is the vulnerability commonly found?

Typical locations are enterprise login forms, address-book searches, group lookups and administrative tools connected to Active Directory or another LDAP-compatible directory.

How does an LDAP filter work?

LDAP search filters combine attributes, values and logical operators. An application might search for a user whose name and status satisfy two conditions. If parentheses, wildcards or operators from untrusted input become part of that filter, the input changes the query logic rather than only the value. A manipulated filter may return multiple accounts, neutralize a condition or expose additional attributes. Distinguished Names use a separate syntax and different escaping rules.

Possible impact

• - Bypass of an incorrectly implemented LDAP-backed login.
• - Enumeration of users, groups, email addresses and organizational structure.
• - Access to records outside the intended search base.
• - Modification of directory data when the service account has write permissions.

Actual reach depends on the search base, requested attributes and service-account permissions. LDAP injection does not automatically mean full Active Directory compromise, but it can disclose sensitive information and enable further attacks.

How is LDAP injection tested?

Testers identify every input that influences directory searches, group checks or Distinguished Names. Controlled special characters and logically equivalent filters reveal whether the result set or authentication decision changes. Error messages, response-time differences and unexpected result counts provide additional clues. In source code, each data flow must clearly identify whether a value reaches a search filter or a Distinguished Name and use the correct contextual escaping function.

Secure architecture around LDAP

Applications should query fixed attributes within a narrow search base. The service account needs access only to the attributes it reads and usually no write permission. TLS protects credentials and directory data in transit, but does not prevent injection. Results should be limited, and sensitive attributes should not be requested in the first place. For authentication, an established identity integration is more robust than custom LDAP filters assembled by the application.