JNDI supports the deserialization of objects from LDAP directories, which can lead to remote code execution.

This rule raises an issue when an LDAP search query is executed with ``++SearchControls++`` configured to allow deserialization.


== Ask Yourself Whether

* The application connects to an untrusted LDAP directory.
* User-controlled objects can be stored in the LDAP directory.

There is a risk if you answered yes to any of those questions.


== Recommended Secure Coding Practices

It is recommended to disable deserialization of LDAP objects.


== Sensitive Code Example

----
DirContext ctx = new InitialDirContext();
// ...
ctx.search(query, filter,
        new SearchControls(scope, countLimit, timeLimit, attributes,
            true, // Noncompliant; allows deserialization
            deref));
----


== Compliant Solution

----
DirContext ctx = new InitialDirContext();
// ...
ctx.search(query, filter,
        new SearchControls(scope, countLimit, timeLimit, attributes,
            false, // Compliant
            deref));
----


== See

* https://cwe.mitre.org/data/definitions/502.html[MITRE, CWE-502] - Deserialization of Untrusted Data
* https://www.owasp.org/index.php/Top_10-2017_A8-Insecure_Deserialization[OWASP Top 10 2017 Category A8] - Insecure Deserialization
* https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE-wp.pdf[BlackHat presentation]
* Derived from FindSecBugs rule https://find-sec-bugs.github.io/bugs.htm#LDAP_ENTRY_POISONING[LDAP_ENTRY_POISONING]