LDAP Injection attacks are popular due to the common use of LDAP to authenticate user. The Lightweight Directory Access Protocol (LDAP) origins started with the set of OSI standards called X.500. The X.500 standards are large and heavy which communicated over the Open Systems Interconnection (OSI) protocol stack. X.500 described the Directory Access Protocol (DAP) for how clients communicate with an X.500 Directory Service. DAP was not broadly implemented due to lack of OSI Stack implementations but core services were extracted and implemented in LDAP and the Novell Directory Service. Any software that dynamically generates LDAP requests, like SQL Injection, can be vulnerable to LDAP Injection if input is not sanitized and then manipulated the dynamic request creation. Since there is no parameterized query interface for LDAP, these attacks are popular due to the common use of LDAP to authenticate user.
LDAP Injection Impact
The Lightweight Directory Access Protocol (LDAP) allows software to construct queries to back end directory services. These queries are frequently made as part of an authentication step. If an attacker can inject their own code into the dynamically generated query then they could bypass the authentication step or potentially assume the rights of another user or administrator. Alternatively, they could extract information not originally intended for the authenticated users authorization level or hijack a valid users session.
Testing for LDAP Injection
LDAP Injection testing can be performed by attempting to inject LDAP Search Filter metacharacters into any external untrusted parameters to determine if the server responds with additional information. If the input parameter is used in a filter query to the directory server then we can attempt to enter information to make the query always true.
Want to check your projects for free?
Examples of LDAP Injection
In this example there is a web application with a login form containing a username and password fields and a login button. Once the user presses the login button the contents of the username and password fields are transferred to code which uses a LDAP search filter to confirm the login credentials. The LDAP filter looks likes this:
(&(USER=username)(PASSWORD=password))
If user input is not sanitized or validated against a whitelist then an attacker could user metacharacters to inject into this filter. If an attacker enters a valid username of :
johnsmith)(&)
And enters any string as a password then the directory server will receive a filter query like this:
(&(USER=johnsmith)(&))(PASSWORD=password))
Since the server only processes the first filter and johnsmith is a valid username then the above statement is always true. If the result is used in an authentication decision then the attacker gains access to the system as johnsmith only for knowing a valid username.
Fixes for LDAP Injection
Perform server-side validation of all user-supplied data
- Ideally the data should be validated against a white list of known-good characters, such as only upper and lower case letters and numbers 0-9. Characters that do not match the expression (such as special or meta characters) should be rejected
- Always do server side validation on user inputs
- Never concatenate strings, leverage the chosen libraries features to create filters programmatically, for example
String filter = "(|(uid=" + userInput + ")(mail=" + userInput + "))";
should be modified to,
Filter filter = Filter.createORFilter(
Filter.createEqualityFilter("uid", userInput),
Filter.createEqualityFilter("mail", userInput));
