We want to avoid LDAP injection in J2EE. Should we just stay away from Lightweight Directory Access Protocol (LDAP)?...
What are the alternatives?
LDAP injection is an application-specific vulnerability that commonly occurs due to missing or weak input validation functions prior to processing and allowing persistence of data in LDAP. This weakness would allow a hacker to use malicious LDAP attributes or Java Naming and Directory Interface (JNDI) API query/store functions to inject or manipulate or steal personal information from an LDAP repository.
LDAP injection is also possible due to exploits of an insecure LDAP lookup configuration (using "Directory Manager") and missing LDAP access control policies.
To prevent LDAP injection, it is always recommended to enforce stringent input validation functions before processing data for LDAP persistence. In the case of an application that relies on client-side data validation, it becomes important to re-verify and validate them on the server side as well. The data validation should verify the input in terms of required LDAP attributes and its known data type, locale, meta characters, format, length, legal values, etc. To prevent issues with insecure LDAP configuration and access control policies, it is often recommended to verify LDAP configuration and enforce principle of least privilege and role-based access control (RBAC) policies.
LDAP injection is also very similar to the SQL injection vulnerability with relational databases (RDBMS). Using RDBMS is not a viable alternative to LDAP. LDAP is a directory protocol commonly used to represent organizational structure and its users as a hierarchy of objects. The hierarchical representation of LDAP information is one of the biggest advantages over RDBMS that helps implement faster lookup, query and delegation of responsibilities based on an organizational structure, sub-organization, location, users, groups, roles and access-control policies.