Skip to main content

Free 30-min security demo  — We'll scan your real code and show live findings, no commitment Book Now

Offensive360
Home / Knowledge Base / LDAP Injection
High CWE-90 A03:2021 Injection

LDAP Injection

LDAP Injection allows attackers to manipulate directory queries, bypass authentication, and extract sensitive directory information. Learn how to detect and prevent it.

Affects: C#JavaPythonPHP

What is LDAP Injection?

LDAP Injection occurs when untrusted user input is embedded directly into an LDAP search filter or Distinguished Name (DN) without proper encoding. LDAP (Lightweight Directory Access Protocol) is widely used for enterprise authentication and directory services (Active Directory, OpenLDAP). An attacker who can manipulate LDAP queries may bypass authentication, enumerate user accounts, extract sensitive attributes, or escalate privileges.

LDAP filters use special characters such as *, (, ), \, and NUL with specific meanings. Injecting these characters into a filter allows an attacker to alter query logic in the same way SQL special characters are used in SQL injection.

How exploitation works

A login form constructs an LDAP filter using user-supplied credentials:

Filter: (&(uid=<username>)(userPassword=<password>))

An attacker supplies *)(uid=*))(|(uid=* as the username:

Filter: (&(uid=*)(uid=*))(|(uid=*)(userPassword=anything))

This collapses the password check, potentially authenticating as any user — a classic authentication bypass. The wildcard * can also be used to enumerate all directory entries when injected into search queries.

Vulnerable code examples

Java / Spring LDAP

// VULNERABLE: User input directly embedded in LDAP filter
public boolean authenticate(String username, String password) {
    String filter = "(&(uid=" + username + ")(userPassword=" + password + "))";
    return ldapTemplate.authenticate("", filter, new AuthenticatedLdapEntryContextMapper());
}

C# / DirectorySearcher

// VULNERABLE: No encoding of user input in LDAP filter
public DirectoryEntry FindUser(string username)
{
    var searcher = new DirectorySearcher();
    searcher.Filter = "(sAMAccountName=" + username + ")"; // Unencoded input
    return searcher.FindOne()?.GetDirectoryEntry();
}

Secure code examples

Java — LDAP encoding with Spring Security

// SECURE: Use LdapEncoder to encode all user input before embedding in filters
import org.springframework.ldap.core.support.LdapEncoder;

public boolean authenticate(String username, String password) {
    String safeUser = LdapEncoder.filterEncode(username);
    String safePass = LdapEncoder.filterEncode(password);
    String filter = "(&(uid=" + safeUser + ")(userPassword=" + safePass + "))";
    return ldapTemplate.authenticate("", filter, mapper);
}

C# — LDAP encoding helper

// SECURE: Encode special LDAP characters before use in filters
public DirectoryEntry FindUser(string username)
{
    var safeUsername = EncodeLdapFilter(username);
    var searcher = new DirectorySearcher();
    searcher.Filter = $"(sAMAccountName={safeUsername})";
    return searcher.FindOne()?.GetDirectoryEntry();
}

private static string EncodeLdapFilter(string input)
{
    // Encode per RFC 4515: escape *, (, ), \, NUL
    return input
        .Replace("\\", "\\5c").Replace("*", "\\2a")
        .Replace("(", "\\28").Replace(")", "\\29")
        .Replace("\0", "\\00");
}

What Offensive360 detects

  • Unencoded filter construction — String concatenation or interpolation used to build LDAP filters with user-supplied data
  • DN injection — User input embedded in Distinguished Names without LdapEncoder.nameEncode() or equivalent
  • Wildcard-permitting filters — Filters that do not restrict wildcard characters in contexts where enumeration is possible
  • Missing LDAP input validation — Absence of encoding calls before LDAP search or bind operations

Remediation guidance

  1. Encode all user input — Use RFC 4515-compliant encoding for filter values and RFC 4514 encoding for DN components before embedding in queries.

  2. Use parameterized LDAP APIs — Some frameworks support parameterized or positional filter construction; prefer these over string concatenation.

  3. Validate input format — Apply strict allow-list validation on usernames and other directory attributes (e.g., alphanumeric + limited special chars).

  4. Enforce least-privilege on the directory bind account — The account used by the application to query LDAP should have read-only access to the minimum required attributes.

  5. Disable anonymous LDAP binding — Ensure directory servers do not allow unauthenticated queries.

References

By Offensive360 Security Research Reviewed: March 2026

Detect LDAP Injection automatically

Run Offensive360 SAST on your codebase to find this and 100+ other vulnerabilities.