What is LDAP injection, and how is it prevented?

LDAP injection happens when an application pastes user input unescaped into a search filter or DN, so characters like *, (, ) or | change the meaning of the query; it is prevented by escaping input, validating it, and binding with least-privilege accounts.

A login form builds the filter (&(uid= + input + )(objectClass=person)). If the attacker types *, the filter becomes (&(uid=*)(objectClass=person)) and matches every person. Worse inputs can close parentheses and add their own conditions, for example *)(|(uid=* to turn the filter into an always-true OR.

Defences:

1. Escape the special filter characters before inserting input: * becomes \2a, ( becomes \28, ) becomes \29, \ becomes \5c, NUL becomes \00 (RFC 4515). For DNs, escape the DN special characters (, + " \ < > ; =) per RFC 4514.
2. Validate input against an allow-list (a user name has no parentheses).
3. Least privilege: the service account used for the search should only see what the application needs.

It is the directory cousin of SQL injection, with the same root cause: mixing code and data in one string.

Go deeper:

• OWASP: LDAP Injection Prevention Cheat Sheet — the escaping rules for filters and DNs, with library recommendations.
• OWASP: LDAP Injection — attack examples against login and search forms.