It all started to go wrong when Web applications started to replace internal desktop applications in many companies around the globe and one manager proposed: "We should authenticate access to this application using our Active Directory!" and after some minutes a developer wrote a piece of code that looked like:

String ldap_search_query = "(&(user=" username ")(password=" pwd "))";

LDAPCursor ldap_result_cursor = ldapQuery( ldap_search_query );

The idea of having a centralized location for authenticating users is actually very good; but as usual the problem lies within the implementation. For LDAP injections - which are very similar in nature to SQL injections - the issue is that the developer is creating an LDAP query by concatenating user controlled variables like "username" and "pwd" with fixed strings like "(&(user=". This results in the user being able to partially control the LDAP query that's being executed on the backend server, thus controlling the result, and finally (in some cases) the application's execution flow.

Let's see what happens when a regular user logs in to the Web application:

User browses to http://web-app/login.aspx

http://web-app/login.aspx User enters his credentials, username: andres / password: foobar

/ password: The web application concatenates the input variables with the fixed strings and sends (&(user=andres)(password=foobar)) to the LDAP server

LDAP server will return the expected info and execution continues as the developer intended



But not all users are that kind, some will try the following:

Intruder browses to http://web-app/login.aspx

http://web-app/login.aspx Intruder wants to impersonate "andres", so he enters the following information, username: andres)(&) / password: notimportant

/ password: The web application concatenates the input variables with the fixed strings and sends (& (user=andres)(&) )(password=notimportant))

The LDAP server is now going to execute a completely different query, which will allow the intruder to bypass the login and impersonate the user



Worried that these types of vulnerabilities might be affecting your Web applications? NeXpose allows you to scan for these and many other types of Web application vulnerabilities. The following is an example of what's shown in NeXpose's web user interface when an LDAP injection is found, including the vulnerable script and parameter:



A couple of important notes to keep in mind are that this type of vulnerability can affect any Web application, disregarding which language it was written in and which LDAP backend it uses. Our detection engine provides coverage for all combinations of ASP.NET, PHP, Python, Ruby, Java and OpenLDAP, ActiveDirectory, OpenDS and many others.

Start increasing the security of your Web applications, request a NeXpose Enterprise Edition trial!