LDAP Injection and Mitigation

RV here...

The Lightweight Directory Access Protocol (LDAP) API provides a mechanism for connecting to, searching, and modifying internet directories. A LDAP (Lightweight Directory Access Protocol) injection attack exploits vulnerabilities in input validation to run arbitrary LDAP statements against information directories. It can occur when your application uses input to construct dynamic LDAP statements to access directory services. Using the LDAP injection attack, the attacker can execute arbitrary statements against the directory services.

In .NET System.DirectoryServices provides multiple classes to search and retrieve information from LDAP stores such as Active Directory. The following code illustrates the vulnerable code.

    1: public string GetUserFullName(string loginName)
    2: {
    3:     //Root entry for contoso.com global catalog
    4:     DirectoryEntry root = new 
    5:         DirectoryEntry("GC://DC=contoso,DC=com");
    6:  
    7:     //Instantiating directory searcher object
    8:     DirectorySearcher searcher = new DirectorySearcher();
    9:     root.AuthenticationType = AuthenticationTypes.Secure;
   10:     searcher.SearchRoot = root;
   11:  
   12:     //Searching the directory for the specified windows login name
   13:     searcher.Filter = string.Format("(sAMAccountName={1})", 
   14:         loginName);
   15:     SearchResult result = searcher.FindOne();
   16:     //Retrieving user common name
   17:     string userName = result.Properties["cn"][0].ToString();
   18:     root.Close();
   19:     //Returning the user name
   20:     return userName;
   21: }

Line 13 in the above code dynamically constructs the LDAP search query which allows the user to completely control the LDAP query. In order to mitigate the above vulnerability input needs to be validated or encoded. Input validation is always the best approach but it still does not make the query valid if input allows one of the special characters in LDAP search query. RFC 4515 : Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters provides detailed information on how the search filters should be formed and what characters need to be escaped or encoded. In this case proper character encoding mitigates the LDAP Injection Vulnerability. The simple character encoding requires each octet of the character to be escaped is replaced by a backslash and two hex digits. In essence a left parenthesis ( can be escaped as \28 and right parenthesis as \29 respectively. The following table shows more complex encoding examples.

To fix the above vulnerable code user input needs to be properly encoded. The next version of Web Protection Library (WPL) will include encoding method for LDAP search strings which will perform above mentioned hex encoding. Similar to Anti-XSS Library, LDAP encoding uses white-list which includes non English character sets such as CJK, Indic Languages etc. Keep checking the blog for more posts on new features in WPL.

Thanks

RV