Because it is easy to extract strings from an application source code or binary, credentials should not be hard-coded. This is particularly true for applications that are distributed or that are open-source.


In the past, it has led to the following vulnerabilities:

* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13466[CVE-2019-13466]
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15389[CVE-2018-15389]

Credentials should be stored outside of the code in a configuration file, a database, or a management service for secrets. 


This rule looks for hard-coded credentials in variable names that match any of the patterns from the provided list.

include::../ask-yourself.adoc[]

include::../recommended.adoc[]

== Sensitive Code Example

----
dbi_conn conn = dbi_conn_new("mysql");
string password = "secret"; // Sensitive
dbi_conn_set_option(conn, "password", password.c_str());
----

== Compliant Solution

[source,cpp]
----
dbi_conn conn = dbi_conn_new("mysql");
string password = getDatabasePassword(); // Compliant
dbi_conn_set_option(conn, "password", password.c_str()); // Compliant
----

== See

* OWASP - https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/[Top 10 2021 Category A7 - Identification and Authentication Failures]
* OWASP - https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication[Top 10 2017 Category A2 - Broken Authentication]
* CWE - https://cwe.mitre.org/data/definitions/798[CWE-798 - Use of Hard-coded Credentials]
* CWE - https://cwe.mitre.org/data/definitions/259[CWE-259 - Use of Hard-coded Password]
* Derived from FindSecBugs rule https://h3xstream.github.io/find-sec-bugs/bugs.htm#HARD_CODE_PASSWORD[Hard Coded Password]

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

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

include::../message.adoc[]

include::../parameters.adoc[]

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

=== on 3 Dec 2020, 11:17:07 Geoffray Adde wrote:
\[~hendrik.buchwald], I did the implementation of the rule in its current state. While doing so, we discussed 3 improvements with [~loic.joly] that could be added to the C/{cpp} version.

* Macros: they are very often used as global variable, especially in C.

----
#define PASSWD secret
----

* For function calls, we could apply the rule to names of parameters (which are a sort of variable). This could catch hard-coded credentials in calls.

----
int connect( const std::string& Url, const std::string& Passwd);
...
connect("124.234.56.7", "secret"); // "secret" is used for parameter Passwd, so we should raise an issue there
----

* Still for the case of hard-coded credentials in function calls. Some libraries/frameworks do something like set(PASSWD, "secret)". So maybe flagging, such function calls with enum named with "passwd" and literals could work.

----
curl_easy_setopt(easyhandle, CURLOPT_USERPWD, "myname:thesecret");
----

What do you think Hendrik?

=== on 3 Dec 2020, 13:53:57 Hendrik Buchwald wrote:
\[~geoffray.adde] all 3 things make sense to me. For the enums it might be hard to detect when they are actually used for assigning literal values though. I fear that just checking for a string literal and an enum with a password-name in a function call might result in too many false-positives. But I don't see a way how to check this before it is implemented. WDYT?

=== on 18 Dec 2020, 08:52:03 Geoffray Adde wrote:
I created https://jira.sonarsource.com/browse/CPP-2852

include::../comments-and-links.adoc[]

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