=== on 2 Oct 2014, 13:42:14 Nicolas Peru wrote:
The relating find-sec-bug rule is :  \http://h3xstream.github.io/find-sec-bugs/bugs.htm#LDAP_INJECTION


it checks for classes with use of methods : 

"com/unboundid/ldap/sdk/LDAPConnection.search(String, SearchScope, String, String[])" or "javax/naming/directory/InitialDirContext.search(String, String, SearchControls)"

And verify that methods ``++search++`` use constant string or string literal (between other "safe values") for parameters when they are called.

=== on 4 Dec 2014, 16:48:08 Freddy Mallet wrote:
I need to validate if the use of http://docs.oracle.com/javase/8/docs/api/javax/naming/directory/DirContext.html#search-javax.naming.Name-java.lang.String-java.lang.Object:A-javax.naming.directory.SearchControls-[filter expression] allows to prevent LDAP injection

=== on 16 Jan 2015, 09:36:17 Sébastien Gioria wrote:
\[~freddy.mallet]: at my lastest knowledge, it's not prevent it. Only solution in LDAP is sanitize datas. 



=== on 9 May 2018, 10:43:03 Dinesh Bolkensteyn wrote:
For the record (and 3 years later), using placeholders in the filter expression will correctly handle escaping, else this method would be pretty useless - cc [~freddy.mallet] [~sebastien.gioria]


So it is wrong to state that the JNDI LDAP API does not provide a functionally similar to SQL prepared statements.


----
String user = "admin";
String pass = "secret";

// Setting this will not bypass authentificated
// Instead it will literally look for such a user ID
// However, if the filter expression is constructed from string concatenation (not the case here), authentifcation would be bypassed
//user="*)(uid=*))(|(uid=*";

NamingEnumeration<SearchResult> results = ctx.search("ou=system", "(&(uid={0})(userPassword={1}))", new String[]{user, pass}, new SearchControls());
if (results.hasMore()) {
  System.out.println("auth'ed!");
} else {
  System.out.println("no such user");
}
----