91 lines
3.5 KiB
Plaintext
91 lines
3.5 KiB
Plaintext
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[]
|