Lightweight Directory Access Protocol (LDAP) is an open and vendor-neutral directory service protocol that runs on a layer above the TCP/IP stack. It provides the appropriate mechanism for the implementation of authentication and authorization controls, things that are commonly used while developing intranet and internet (web) applications.
LDAP servers store information that is accessed by clients using LDAP sessions (usually with pre-defined time-outs). The most basic actions that are taken once the session is initiated are the adding, deleting and modifying of entries. Other operations that are frequently executed include:
- Bind – to authenticate and specify LDAP the LDAP protocol version.
- Search – to locate and retrieve LDAP directory entries.
- Compare – to test if a names entry contains a given attribute value.
- Extended Operation – an operation used to define unique operations.
- Unbind – close the connection.
As evident in the diagram above, LDAP injections are basically crafted queries. Under normal circumstances, normal queries to the LDAP server lead to normal output. But when the malicious attacker sends LDAP statements along with code injections, additional private and sensitive information can be stolen from the LDAP servers.
Advanced LDAP injections can also allow the attacker to enable the execution of arbitrary commands to gain unauthorized permissions and even modify information within the LDAP tree. Besides these advanced injections, many techniques used in the SQL injection can also be implemented in the LDAP injection.
In a page with a user search form, the following code is responsible to process user input value and generate a LDAP query that will be used in LDAP database.
Insert the username
The LDAP query is narrowed down for performance and the underlying code for this function might be the following:
String ldapSearchQuery = “(cn=” + $userName + “)”; System.out.println(ldapSearchQuery);
If the variable $userName is not validated, it could be possible to accomplish LDAP injection, as follows:
If a user puts “*” on box search, the system may return all the user objects on the LDAP base.
In a login form, for instance, the following vulnerable code could be used:
If there is no input validation the user can insert the following injection in the user and pass fields:
user = )(uid=))(|(uid= pass = password*
The search filter would then return the first user in the LDAP tree and allow the attacker to bypass authentication:
LDAP flaws are basically application-layer vulnerabilities. This means that conventional security provisions like firewalls and intrusion detention tools are not effective in detecting LDAP injections. While minimum exposure points and “minimum privilege” principles are helpful, the real solutions to these issues include:
- Safe LDAP Configuration – This involves the safeguarding of sensitive information and data in the LDAP directory, especially while dealing with permissions on user objects. This is all the more important when the directory is used by the web/mobile application for a single logging-on process.
- Advanced input validation – All user-end input must be sanitized thoroughly. It should be free of suspicious characters and strings that can be malicious.
- Output regulation – Limits and restrictions should also be placed on the amount of data/information returned by the LDAP servers to the client.
CxSAST locates LDAP injection vulnerabilities by following all user input that is used as part of an LDAP command and warns if the input has not been validated or checked.