ABSTRACT

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

EXPLANATION

LDAP injection errors occur when:

1. Data enters a program from an untrusted source.

2. The data is used to dynamically construct a 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 can 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.

REFERENCES

[1] Standards Mapping - OWASP Top 10 2010 - (OWASP 2010) A1 Injection

[2] Standards Mapping - OWASP Top 10 2007 - (OWASP 2007) A2 Injection Flaws

[3] Standards Mapping - OWASP Top 10 2004 - (OWASP 2004) A6 Injection Flaws

[4] Standards Mapping - Security Technical Implementation Guide Version 3 - (STIG 3) APP3510 CAT I

[5] Standards Mapping - Common Weakness Enumeration - (CWE) CWE ID 90

[6] Standards Mapping - SANS Top 25 2009 - (SANS 2009) Insecure Interaction - CWE ID 116

[7] Standards Mapping - Web Application Security Consortium 24 + 2 - (WASC 24 + 2) LDAP Injection

[8] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 - (PCI 1.2) Requirement 6.3.1.1, Requirement 6.5.2

[9] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 - (PCI 2.0) Requirement 6.5.1

[10] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 - (PCI 1.1) Requirement 6.5.6

[11] Standards Mapping - FIPS200 - (FISMA) SI