LDAP Injection

Constructing a dynamic LDAP filter with user input could allow an attacker to modify the statement's meaning.

LDAP injection errors occur when:

1. Data enters a program from an untrusted source.

In this case, Fortify Static Code Analyzer could not determine that the source of the data is trusted.

2. The data is used to dynamically construct an LDAP filter.
Example 1: The following code dynamically constructs and executes an LDAP query that retrieves records for all the employees who report to a given manager. The manager's name is read from an HTTP request, and is therefore untrusted.

...
DirectorySearcher src =
           new DirectorySearcher("(manager=" + managerName.Text + ")");
src.SearchRoot = de;
src.SearchScope = SearchScope.Subtree;

foreach(SearchResult res in src.FindAll()) {
  ...
}

Under normal conditions, such as searching for employees who report to the manager John Smith, the filter that this code executes will look like the following:

(manager=Smith, John)

However, because the filter is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if managerName does not contain any LDAP meta characters. If an attacker enters the string Hacker, Wiley)(|(objectclass=*) for managerName, then the query becomes the following:

(manager=Hacker, Wiley)(|(objectclass=*))

Based on the permissions with which the query is executed, the addition of the |(objectclass=*) condition causes the filter to match against all entries in the directory, and allows the attacker to retrieve information about the entire pool of users. Depending on the permissions with which the LDAP query is performed, the breadth of this attack may be limited, but if the attacker may control the command structure of the query, such an attack can at least affect all records that the user the LDAP query is executed as can access.

Constructing a dynamic LDAP filter with user input could allow an attacker to modify the statement's meaning.

LDAP injection errors occur when:

1. Data enters a program from an untrusted source.

2. The data is used to dynamically construct an LDAP filter.
Example 1: The following code dynamically constructs and executes an LDAP query that retrieves records for all the employees who report to a given manager. The manager's name is read from a network socket, and is therefore untrusted.

fgets(manager, sizeof(manager), socket);

snprintf(filter, sizeof(filter, "(manager=%s)", manager);

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

Under normal conditions, such as searching for employees who report to the manager John Smith, the filter that this code executes will look like the following:

(manager=Smith, John)

However, because the filter is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if manager does not contain any LDAP meta characters. If an attacker enters the string Hacker, Wiley)(|(objectclass=*) for manager, then the query becomes the following:

(manager=Hacker, Wiley)(|(objectclass=*))

Based on the permissions with which the query is executed, the addition of the |(objectclass=*) condition causes the filter to match against all entries in the directory, and allows the attacker to retrieve information about the entire pool of users. Depending on the permissions with which the LDAP query is performed, the breadth of this attack may be limited, but if the attacker may control the command structure of the query, such an attack can at least affect all records that the user the LDAP query is executed as can access.

Constructing a dynamic LDAP filter with user input could allow an attacker to modify the statement's meaning.

LDAP injection errors occur when:
1. Data enters a program from an untrusted source.

2. The data is used to dynamically construct an LDAP filter.
Example 1: The following code dynamically constructs and executes an LDAP query that retrieves records for all the employees who report to a given manager. The manager's name is read from an HTTP request, and is therefore untrusted.

...
$managerName = $_POST["managerName"]];

//retrieve all of the employees who report to a manager

$filter = "(manager=" . $managerName . ")";

$result = ldap_search($ds, "ou=People,dc=example,dc=com", $filter);
...

Under normal conditions, such as searching for employees who report to the manager John Smith, the filter that this code executes will look like the following:

(manager=Smith, John)

However, because the filter is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if managerName does not contain any LDAP meta characters. If an attacker enters the string Hacker, Wiley)(|(objectclass=*) for managerName, then the query becomes the following:

(manager=Hacker, Wiley)(|(objectclass=*))

Based on the permissions with which the query is executed, the addition of the |(objectclass=*) condition causes the filter to match against all entries in the directory, and allows the attacker to retrieve information about the entire pool of users. Depending on the permissions with which the LDAP query is performed, the breadth of this attack may be limited, but if the attacker may control the command structure of the query, such an attack can at least affect all records that the user the LDAP query is executed as can access.