Defect: Password / Login (Category Security 2)
Diagnose: Hard-coded literals are used as parameters in functions known to be password protected
DeepCode learns from open source repositories. As an example, we know what are typical sources of passwords or secrets in applications. Typically, functions that read in from a protected configuration store. We trace the flow this data takes through open-source applications and are able to identify typical sinks or users of these secrets (e.g., database or API logins). After we identified these sinks, we can now enforce that no secret data results from a source that is not protected, such as a hard-coded constant in your source code.
Obviously, having your passwords hard-coded in your application is a bad practice. The Common Weakness Enumeration lists it twice: Both CWE 259 Use of Hard-Coded Passwords and CWE 798 Use of Hard-Coded Credentials. OWASP also lists it.
Besides the risk of leaking password information to your dev team or anyone else having access to your source code, it makes it extremely hard to change the password for the operational side. I guess it is a no-brainer to not plaster secret keys into files they do not belong in. ‘nough said.
But there is another interesting aspect to this. We see quite some false positives with this bug. The reason is that it might be legitimate to use the functions with a hard-coded password in testing or when both systems interacting are trusting each other by default. Yes, we can have discussions now if this practice is legitimate or not. But, let us accept it for now. Obviously, false positives are something we would like to prevent as much as possible. So, what shall we do?
We decided on the strict side of things. We accept some false positives but rather report possible issues. If you want to prevent false positives, we offer two ways: (1) With the .dcignore file (see here ) or (2) by adding a comment in your file (see here ). Better safe than sorry. So, give it a run at deepcode.ai …