The application architecture that supports LDAP includes both server-side and client-side components. The LDAP queries submitted to the server are known as LDAP search filters, which are constructed using prefix notation. Below is an example of an LDAP search filter:
find("(&(cn=" + username +")(userPassword=" + pass +"))")
This prefix filter notation instructs the query to find an LDAP node with the given username and password. Consider a scenario where this query is constructed by appending the username and password strings obtained from an HTML form. If these user-controlled values are appended to the LDAP search filter without any validation or sanitization, a username and password value of ‘*’ changes the intended meaning of the query and returns a list of all users.
Special characters other than ‘*’ can also create malicious queries. If the username value is set to ‘*)(cn=*))(|(cn=*’, the effective search filter becomes:
find("(&(cn=*)(cn=*))(|(cn=*)(userPassword=" + pass +"))")
The highlighted condition in the above query always evaluates to true. If this query is used within an authentication flow, an attacker can easily bypass authentication controls with the above payload.
There are a multitude of LDAP injection exploits that can be executed against a vulnerable server. Additionally, LDAP servers often store information such as users, roles, permissions, and related objects provisioned to them which, if compromised, can be devastating.