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

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


== See

* https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/[OWASP Top 10 2021 Category A8] - Software and Data Integrity Failures
* https://cwe.mitre.org/data/definitions/502[MITRE, CWE-502] - Deserialization of Untrusted Data
* https://owasp.org/www-project-top-ten/2017/A8_2017-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]


ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

include::message.adoc[]

include::highlighting.adoc[]

'''
== Comments And Links
(visible only on this page)

include::comments-and-links.adoc[]
endif::env-github,rspecator-view[]