LDAP Injection Guide: Learn How to Detect LDAP Injections and Improve LDAP Security

Lightweight Directory Access Protocol (LDAP) Injection

LDAP injection security cheat sheetLDAP is a widely used open-standard protocol for both querying and manipulating information directories. The LDAP protocol runs over Internet transport protocols, such as TCP. Web applications may use user-supplied input to create custom LDAP statements for dynamic web page requests. LDAP injection is the technique of exploiting web applications that use client-supplied data in LDAP statements without first stripping potentially harmful characters from the request.

When a web application fails to properly sanitize user-supplied input, it is possible for an attacker to alter the construction of an LDAP statement. When an attacker is able to modify an LDAP statement, the process will run with the same permissions as the component that executed the command. (e.g. Database server, Web application server, Web server, etc.). This can cause serious security problems where the permissions grant the rights to query, modify or remove anything inside the LDAP tree.

 

LDAP injection example

Why be concerned about LDAP Injection?

Lightweight Directory Access Protocol (LDAP) Injection is an attack used to exploit web based applications that construct LDAP statements based on user input. When an application fails to properly sanitize user input, it’s possible to modify LDAP statements using a local proxy. This could result in the execution of arbitrary commands such as granting permissions to unauthorized queries, and content modification inside the LDAP tree. The same advanced exploitation techniques available in SQL Injection can be similarly applied in LDAP Injection.

Example of LDAP Injection

The following code dynamically constructs and executes an LDAP query that retrieves records for all the employees who report to a given manager. The manager's name is read from an HTTP request, and is therefore untrusted.
...
DirectorySearcher src = new DirectorySearcher("(manager=" + managerName.Text + ")");
src.SearchRoot = de;
src.SearchScope = SearchScope.Subtree;

foreach(SearchResult res in src.FindAll()) {
...
}

Under normal conditions, such as searching for employees who report to the manager John Smith, the filter that this code executes will look like the following:
(manager=Smith, John)

However, because the filter is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if managerName does not contain any LDAP meta characters. If an attacker enters the string Hacker, Wiley)(|(objectclass=*) for managerName, then the query becomes the following:
(manager=Hacker, Wiley)(|(objectclass=*))

LDAP Security: Finding and Remediating LDAP Injection Vulnerabilities

Mechanisms used to prevent code injection techniques include defensive programming, sophisticated input validation, dynamic checks and static source code analysis. The work on mitigating LDAP injections must involve similar techniques. LDAP injection attacks are performed by including special characters in the parameters send from the client to the server. It is very important to check and sanitize the variables used to construct the LDAP filters before sending the queries to the server.

LDAP Injection and other types of Injection Attacks occur when an application (web or desktop application) sends to the LDAP interpreter user supplied data inside the filter options of the statement. When an attacker supplies specially crafted data, the possibility to create, read, delete or modify arbitrary data gets unlocked. The most effective mitigation mechanism is to assume that all user inputs are potentially malicious. User inputs must always be sanitized on server side (in order to avoid client side data manipulation) before passing the parameter to the LDAP interpreter. This sanitizing procedure can be done in two different ways.
 

  • The easiest one consists of detecting a possible injection attack by analyzing the parameter looking for certain known patterns attacks, aided by different programming techniques, like regular expressions. This technique has the main disadvantage of false positive cases. By applying this mechanism we might be excluding valid user inputs, mistaking them as invalid parameters. As an example Parentheses, asterisks, logical (AND "&", OR "|" and NOT "!") and relational (=,>=,<=,~=) operators should be filtered at the application layer.
  • The second approach may include trying to modify the received user input to adapt it into a harmless one. This way, sanitizing the input would reduce the false positive cases. Whenever possible, values used to construct the LDAP search filter must be checked against a list of valid values in the Application Layer before sending the query to the LDAP server.

 

Preventing LDAP Injection Vulnerabilities

Protecting LDAP-enabled web applications demands the effort of developers as well as the LDAP administrators. Though effective at reducing the risk of such an attack, the approaches discussed in the next section are not complete solutions. It is best to remember that web application security, by its own definition, must be a continually evolving process. As hackers change their methodologies, so must those who want to implement a secure Web application.

Incoming Data Validation - All client-supplied data needs to be cleaned of any characters or strings that could possibly be used maliciously. This should be done for all applications, not just those that use LDAP queries. Stripping quotes or putting backslashes in front of them is nowhere near enough. The best way to filter data is with a default-deny regular expression that includes only the type of characters that you want. For instance, the following regular expression will return only letters and numbers:
s/[^0-9a-zA-Z]//g 

Make your filter as specific as possible. Whenever possible use only numbers. After that, numbers and letters only. If you need to include symbols or punctuation of any kind, make absolutely sure to convert them to HTML substitutes (such as " "e; " or " > "). For instance, if the user is submitting an email address, allow only the "at" sign, underscore, period, and hyphen in addition to numbers and letters, and only after those characters have been converted to their HTML substitutes.

Outgoing Data Validation - All data returned to the user should be validated and the amount of data returned by the queries should be restricted as an added layer of security.

LDAP Configuration - Implementing tight access control on the data in the LDAP directory is imperative, especially when configuring the permissions on user objects, and even more importantly if the directory is used for single sign-on solution. You must fully understand how each objectclass is used and decide if the user should be allowed to modify it. Allowing users to modify their uidNumber attribute, for example, may let the user change access levels when accessing systems. The access level used by the Web application to connect to the LDAP server should be restricted to the absolute minimum required. That way, even if an attacker manages to find a way to break the application, the damage would be limited. In addition, the LDAP server should not be directly accessible on the Internet, thereby eliminating direct attacks to the server itself.

Free LDAP Injection Cheat Sheet: Improve Your LDAP Security

The LDAP Injection Cheat Sheet provides a summary of what you need to know about LDAP Injection. It contains a LDAP Injection example and details of how to protect against LDAP Injection vulnerabilities for maximum LDAP security measures.

Download a FREE LDAP Injection Cheat Sheet

More FREE Security Threat Guides from Veracode

Written by: