LDAP Injection
Severity: High
Test name: LDAP Injection
Test ID: ldapi
Test name: LDAP Injection
Test ID: ldapi
Summary |
---|
LDAP injection targets web applications that compile LDAP (Lightweight Directory Access Protocol) queries using user inputs that have not been adequately sanitized. When a server-side application sends a request to an LDAP server, it may include filter parameters derived from user input. LDAP servers act as repositories for sensitive and valuable information, including user credentials, staff names and roles, network configurations, devices, and contact details. This vulnerability can be exploited to manipulate LDAP queries and gain unauthorized access to this critical information.
Impact |
---|
This vulnerability may lead to the following:
- Bypass authentication. An attacker can gain access without password-checking.
- Information disclosure. An attacker can gain a list of some resources or users.
- Attribute disclosure. An attacker can check if an attribute exists.
Example |
---|
Example 1
- In a web application, we have the following LDAP statement for authorization:
(&(user=username)(password=pass))
- If an attacker sends
user=realUserName)(&)
and any value for password like:
(&(user=realUserName)(&))(password=randomPassword))
- LDAP will process only this part:
(&(user=realUserName)(&)
. This query is always correct, so the attacker enters the system without a true password.
Example 2
- There is a LDAP statement where
resource1
andresource2
are input parameters:
(|(resource=resource1)(resource=resource2))
- The LDAP query was changed like:
resource = resource1)(userId=*)
(|(resource=resource1)(userId=*))(resource=resource2))
- The server will ignore the part
(resource=resource2)
(only the first complete filter is processed). As a result, it will list all the resources that correspond to “resource1" and additionally all user objects.
Location |
---|
The issue can be found in the source code on the server side.
Remedy suggestions |
---|
- Escape all variables using the right LDAP encoding function.
- Wherever possible, use the whitelist approach for input validation. Additional input validation can detect unauthorized input before it is passed to the LDAP query.
- Use the frameworks that automatically protect against the LDAP Injection (like LINQtoAD for .NET).
- To decrease the potential damage caused by a successful LDAP injection, you should minimize the privileges assigned to the LDAP binding account in your environment.
Classifications |
---|
- CWE-90
- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
References |
---|
Updated 4 months ago