java-security: LDAP Injection issue in java

Executing an LDAP statement that contains a user-controlled value outside the filter string can allow an attacker to alter the statement´s meaning or execute arbitrary LDAP commands.


LDAP manipulation errors occur when:

1. Data enters a program from an untrusted source.

2. The data is used outside the filter string in a dynamic LDAP statement.


Example 1: The following code reads a dn string from a socket and uses it to perform an LDAP query.



...
rc = ldap_simple_bind_s( ld, NULL, NULL );
if ( rc != LDAP_SUCCESS ) {
...
}
...

fgets(dn, sizeof(dn), socket);

if ( ( rc = ldap_search_ext_s( ld, dn, LDAP_SCOPE_BASE,
filter, NULL, 0, NULL, NULL, LDAP_NO_LIMIT,
LDAP_NO_LIMIT, &result ) ) != LDAP_SUCCESS ) {
...


Because base DN originates from user input and the query is performed under an anonymous bind, an attacker could alter the results of the query by specifying an unexpected dn string. The problem is that the developer failed to leverage the appropriate access control mechanisms necessary to restrict subsequent queries to access only employee records the current user is permitted to read.



Some times LDAP also happens while performing operation with database. Let´s consider the following example...


public ResultSet queryResult(Connection con, String query) throws SQLException
{
Statement s = con.createStatement();
ResultSet results = s.executeQuery(query);
return results;
}

This method invokes a SQL query built using unvalidated input. This call could allow an attacker to modify the statement´s meaning or to execute arbitrary SQL commands.

How to validate the input parameters in a SQL query to avoid SQL-injection?


Assuming you work with Java you should use Prepared Statements. A prepared Statement is a precompiled statement (as opposed to dynamic SQL statements). You can define specific points in the statement where you want to insert parameters (called parameter markers the ?). In your code you can then assign (bind) values to these predefined parameter markers (eg. userid and password in the example). SQL injection is not possible with such a statement.

PreparedStatement stmt = connection.prepareStatement("SELECT * FROM users WHERE userid=? AND password=?");
stmt.setString(1, userid);
stmt.setString(2, password);
ResultSet rs = stmt.executeQuery();

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.