APaliseno095400 (Community Member) asked a question.
In the code snippet below, when trying to create a new InitialDirContext, the line is flagged for CWE-502. We are not explicitly using a DN (Distinguished Name). We are just passing the userid/password as plaintext.
The types of authentication falls under Name/Password Authentication of Simple Bind: https://ldapwiki.com/wiki/Simple%20Authentication.
Some sources indicate that these fields should be escaped such as: https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html
However there is nothing on https://docs.veracode.com/r/Supported_Java_Cleansing_Functions that is approved for this flaw.
What is the proper handling of this scenario?
public class LDAPTest {
public static void main(String [] args) throws NamingException {
Hashtable<String, String> env = new Hashtable<>();
env.put(Context.INITIAL_CONTEXT_FACTORY, "");
env.put(Context.PROVIDER_URL, "");
env.put(Context.SECURITY_PRINCIPAL, args[0]);
env.put(Context.SECURITY_CREDENTIALS, args[1]);
InitialDirContext dir = new InitialDirContext(env);
}
}
.png){kind=logo}
Hello @APaliseno095400
Thanks for your question. Veracode Static Analyzer reports CWE-502 in your code sample because is sees there is a source of external, untrusted tainted input that is used to construct and bind this LDAP connection and query. The external input in this case most likely attributed to the username and password arg values you set within the env object ( the args[] array is a well known source of taint Veracode looks out for). The InitialDirContext method is specifically highlighted for CWE-502 as it is part of the JNDI API which permits the deserialization of data coming in from LDAP objects and directories. Allowing tainted input as part of the LDAP instance you are constructing using this setup can put your application at risk of remote code execution, JNDI injection, Denial of Service, or any other undesirable state that can be realized if the tainted input should pass in an unsafe deserialization payload.
For more information on the dangers of allowing external untrusted inputs to flow into an LDAP connection that utilizes the JNDI API, Veracode has published a blog post on this topic that you can read at https://www.veracode.com/blog/research/exploiting-jndi-injections-java . Another good reference is https://blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE-wp.pdf .
The general recommendation we give here to manage this kind of issue is for you to validate all outside tainted input sources to your LDAP construction using an allowlist of acceptable characters. Limiting the valid characters that can come in greatly helps reduce the potential for unsafe deserialization attempts. Enforcing string length boundaries also helps. This validation should take place before you invoke the InitialDirContext method. After you've implemented and tested this works in preventing deserialization attacks that are of greatest concern to your application's use case (reach out to your Security Team for help with this as needed), please raise a mitigation by design proposal in the Veracode Platform. Have your security team review and confirm it has been mitigated properly per your organization's security requirements (note they may also choose to specify additional mitigation requirements here). For steps regarding the mitigation proposal and review process, please check out our documentation at https://docs.veracode.com/r/improve_mitigation . Please be aware that Veracode cannot approve mitigations you submit through this process.
> We are just passing the userid/password as plaintext.
I'd suggest checking with your security team how you are choosing to initialize your LDAP setup and connection here to make sure this is not introducing an insecure credential handling issue. It is normally not suggested to handle cleartext credentials. You at least want to make sure that you have some form of secure TLS transport in effect to keep these safe during runtime (The one ldapwiki you referenced also points this out as a disclaimer). That said, I did notice how the code sample you shared suggests possible Testing code, so it may be the case that this was just an issue found while scanning a non-sensitive LDAP testing environment using dummy test account credentials. It could be that there is no immediate meaningful security risk with this particular example, but your security team should have the final say on this.
Please let me know if you have any further questions regarding this issue. If you have any specific details about your scan report and use case you want to discuss, please arrange a consultation call to talk through those details (https://docs.veracode.com/r/t_schedule_consultation)
Best Regards,
Andrew Bell