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.

Input Encoded Input
(o=Parens R Us (for all your parenthetical needs)) (o=Parens R Us \28for all your parenthetical needs\29)
(cn=***) (cn=*\2A*)
(filename=C:\MyFile) (filename=C:\5cMyFile)
(bin=NULLNULLNULLEOT) (bin=\00\00\00\04)
(sn=Lučić) (sn=Lu\c4\8di\c4\87)

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