rspec/rules/S2078/comments-and-links.adoc

43 lines
1.9 KiB
Plaintext

=== 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");
}
----