Using JNDI may deserialize user input via the `Serializable` API which is extremely dangerous


The problem

JNDI (“Java Naming and Directory Interface”) is a Java JDK API representing an abstract directory service such as DNS, a file system or LDAP. Critically, JNDI allows Java objects to be serialized and deserialized on the wire in implementing systems. This means that if a Java application is allowed to perform a JNDI lookup over some transport protocol then the server it connects to can execute arbitrary attacker-defined code. See this Black Hat talk for more information.

This checker bans usage of every API in the Java JDK that can result in deserialising an unsafe object via JNDI. The list of APIs is generated from static callgraph analysis of the JDK, rooted at javax.naming.Context.lookup and is as follows:

A small subset of these are banned directly. The rest are banned indirectly by banning the lookup(), bind(), rebind(), getAttributes(), modifyAttriutes(), createSubcontext(), getSchema(), getSchemaClassDefinition() and search() methods on any subclass (implementer) of javax.naming.Context. The indirect ban is necessary due to these methods being vulnerable in previously noted subclasses in the JDK. If they were not banned at the Context level, a cast to Context would make the vulnerable call invisible to static analysis.


Suppress false positives by adding the suppression annotation @SuppressWarnings("BanJNDI") to the enclosing element.