LDAP Injection
debt(d5/e3/b3/t7)
Closest to 'specialist tool catches it' (d5): detection_hints lists semgrep and psalm as the tools, both specialist SAST tools rather than default linters. The code pattern (string concatenation into LDAP filters without ldap_escape()) is detectable statically but requires dedicated SAST configuration, not a default linter rule. In production, the vulnerability is silent until actively exploited.
Closest to 'simple parameterised fix' (e3): The quick_fix is to replace raw concatenation with ldap_escape() calls using the correct context flag (LDAP_ESCAPE_FILTER or LDAP_ESCAPE_DN). This is a small, targeted refactor within the affected query/filter construction sites — not a one-line global patch, but also not a cross-file architectural change. Multiple call sites may need updating, keeping it at e3.
Closest to 'localised tax' (b3): The vulnerability applies to web and CLI contexts but only where LDAP queries are constructed. It does not impose a persistent codebase-wide tax; only the LDAP-touching components carry the risk. Once ldap_escape() is used consistently in those components, the burden is contained.
Closest to 'serious trap' (t7): The misconception field explicitly states that developers believe 'LDAP injection is rare and low impact,' when in fact it can bypass authentication entirely and enumerate sensitive directory data. This contradicts intuition shaped by familiarity with SQL injection — LDAP's filter syntax is different, the escape function (ldap_escape()) requires a context flag, and the impact (auth bypass, attribute enumeration) is underestimated by most developers. This is a well-documented but frequently missed trap.
Also Known As
TL;DR
Explanation
LDAP injection is analogous to SQL injection but targets Lightweight Directory Access Protocol queries. If user-supplied values are concatenated directly into an LDAP filter string, an attacker can alter the query logic — for example, injecting *)(&) to match all entries or bypass authentication checks. PHP applications using ldap_search() must escape special characters with ldap_escape() before building filter strings.
How It's Exploited
Common Misconception
Why It Matters
Common Mistakes
- Concatenating user input into LDAP filter strings without using ldap_escape().
- Not specifying LDAP_ESCAPE_FILTER or LDAP_ESCAPE_DN context in ldap_escape() calls.
- Binding to LDAP with an admin account for all operations instead of a restricted read-only account.
- Believing that LDAP is only used for authentication and therefore less exploitable than SQL databases.
Code Examples
$filter = "(uid=$username)"; ldap_search($conn, $base, $filter);$safe = ldap_escape($username, '', LDAP_ESCAPE_FILTER); ldap_search($conn, $base, "(uid=$safe)");