LDAP Injection [CWE-90]

LDAP Injection weakness describes improper neutralization of special elements used in LDAP queries.

Created: February 23, 2013

Latest Update: July 29, 2020



Table of Content

Want to have an in-depth understanding of all modern aspects of LDAP Injection [CWE-90]? Read carefully this article and bookmark it to get back later, we regularly update this page.

1. Description

This weakness describes a case where software does not properly validate external input before using it to construct LDAP queries. As a result, an attacker might be able to inject and execute arbitrary LDAP commands within the directory server.

Let's assume we have a simple front-end application that performs search in Active Directory on provided login and outputs information. Our script consist of two parts: html form and PHP code:

HTML form



< form method = "post" action = "" > < p > Login: < input type = "text" name = "user" value = "" >< / p > < p > Password: < input type = "password" name = "pass" value = "" >< / p > < p > Search for: < input type = "text" name = "login" >< / p > < input type = submit name = "submit" value = "Enter" > < / form >

<? ... $username = htmlspecialchars ( trim ( $_POST [ "user" ] ) ) ; $upasswd = htmlspecialchars ( trim ( $_POST [ "pass" ] ) ) ; $ldapbind = ldap_bind ( $ds , $username , $upasswd ) ; if ( $ldapbind ) : $filter = "(&(objectClass=user)(sAMAccountName=" . htmlspecialchars ( $_REQUEST [ "login" ] ) . "))" ; if ( ! ( $search =@ ldap_search ( $ds , $ldapconfig [ 'basedn' ] , $filter ) ) ) { echo ( "Unable to search ldap server<br>" ) ; echo ( "msg:'" . ldap_error ( $ds ) . "'</br>" ) ; #check the message again } else { $number_returned = ldap_count_entries ( $ds , $search ) ; $info = ldap_get_entries ( $ds , $search ) ; echo "<p>The number of entries returned is " . $number_returned . "<p><pre>" ; for ( $i = 0 ; $i < $info [ "count" ] ; $i ++ ) { print_r ( $info [ $i ] ) ; } echo "</pre>" ; } endif ; ?>

The script is intended to output information on user account passed to $_REQUEST["login"] variable.

A regular LDAP query should look like:

(&(objectClass=user)(sAMAccountName=test_account))

The script however does not escape special symbols, which can be used by an attacker to abuse the functionality and perform arbitrary searches on directory server.

An attacker can modify the LDAP request and construct a new one by replacing the logon name with LDAP commands:

(&(objectClass=user)(sAMAccountName=*)(memberof=CN=Domain Admins,CN=Users,DC=testcompany,DC=local))

Once executed the script will return information on all administrative users in Active Directory.

In our scenario, this weakness can be used by attacker to access potentially sensitive information for later use in other attacks. For example, an attacker can enumerate user accounts and perform a brute-force attack or gain excessive knowledge of network infrastructure, quantity of computers and employees, etc.

2. Potential impact

Depending on the vulnerable application and its functionality, an attacker might be able to gain access to potentially sensitive information, modify or delete data and elevate privileges within the application. In a worst-case scenario this weakness could lead to full system compromise.

How to Detect LDAP Injection Vulnerabilities Free Website Security Test Non-intrusive GDPR Test

Non-intrusive PCI DSS Test Try Free Test ImmuniWeb® On-Demand Complete GDPR Audit

Complete PCI DSS Audit

Remediation Guidelines

DevSecOps Integration Learn More

3. Attack patterns

Common Attack Pattern Enumeration and Classification (CAPEC) contains exploitation patterns for this weakness:

Alternative threat classification from WASC describes this weakness as an attack technique WASC-29 (LDAP Injection).

4. Affected software

Software that uses directory server to store and access information is potentially vulnerable to this weakness. Many corporate applications use SSO functionality based on LDAP and therefore should pay extra attention to security of such software.

5. Mitigations

Protection against LDAP injections requires accurate coding and secure server configuration.

Front-end applications should perform input validation and restrict all potentially malicious symbols. Developers can use regular expressions to validate untrusted input. The following regular expression can limit the scope of potential attacks by allowing only numbers and letters:

/[^0-9a-z]/i

Perform filtration of outgoing data as additional level of security. Do not output information that is not related to application’s functionality.

Implement correct access control on data within the LDAP directory, set appropriate permissions on user objects and disable anonymous access to directory objects.

6. Severity and CVSS Scoring

LDAP injections just like any other code injection weaknesses can influence confidentiality, integrity and availability of the application. Depending on application functionality and usage of LDAP queries, an attacker might be able to read, modify, delete information stored in directory server or even elevate privileges.

In case of information disclosure for unprivileged user, this weakness should be scored as:

5.3 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N] – Medium severity.

In case of unauthorized data manipulation, this weakness should be scored as:

6.5 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L] – Medium severity.

In case of authentication bypass and privilege escalation, this weakness can be scored as:

9.8 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H] – Critical severity.

7. References

Copyright Disclaimer: Any above-mentioned content can be copied and used for non-commercial purposes only if proper credit to ImmuniWeb is given.