← Concepts

阅读中文版本

LDAP Injection

LDAP injection injects filter metacharacters into directory queries, letting an attacker widen a search or bypass an authentication check.

security

Definition

LDAP injection is an attack that exploits unescaped user input in a directory filter expression, altering the query's logic so it matches unintended entries.

Context and scope

It matters for enterprise authentication and directory search endpoints that build filters from user-supplied names or identifiers.

Common misconceptions

  • LDAP filters are safe because they are not SQL
  • escaping only special characters is sufficient for every context

Anti-patterns

  • concatenating a username into a search filter
  • validating input only for length while allowing filter syntax characters

Related concepts

Related examples

Authoritative source

https://owasp.org/www-community/attacks/LDAP_Injection

Definition

LDAP injection is an attack that exploits unescaped user input in a directory filter expression, altering the query’s logic so it matches unintended entries.

It matters for enterprise authentication and directory search endpoints that build filters from user-supplied names or identifiers. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.

When to use it

A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.

How it works

Filter metacharacters such as parentheses, asterisks, and logical operators can change the structure of an expression, so a login filter may match more than one identity.

Escape special characters according to the directory specification and prefer APIs that accept a filter template with bound parameters over string building.

Trade-offs and alternatives

Authentication should bind as the user rather than search for a user and compare a stored password, because the search step is a common injection sink. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.

Common misconceptions

A persistent misconception is that LDAP filters are safe because they are not SQL. Another is that escaping only special characters is sufficient for every context. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.

Anti-patterns to avoid

Two recurring anti-patterns are to concatenating a username into a search filter and to validating input only for length while allowing filter syntax characters. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include HTTP Response Splitting, Rainbow Tables and Lookup Attacks, Password Salting.