mirror of
https://github.com/github/codeql.git
synced 2026-02-05 01:31:08 +01:00
83 lines
2.8 KiB
XML
83 lines
2.8 KiB
XML
<!DOCTYPE qhelp PUBLIC
|
|
"-//Semmle//qhelp//EN"
|
|
"qhelp.dtd">
|
|
<qhelp>
|
|
|
|
<overview>
|
|
<p>
|
|
Including unencrypted hard-coded inbound or outbound authentication credentials within source code
|
|
or configuration files is dangerous because the credentials may be easily discovered.
|
|
</p>
|
|
<p>
|
|
Source or configuration files containing hard-coded credentials may be visible to an attacker. For
|
|
example, the source code may be open source, or it may be leaked or accidentally revealed.
|
|
</p>
|
|
<p>
|
|
For inbound authentication, hard-coded credentials may allow unauthorized access to the system. This
|
|
is particularly problematic if the credential is hard-coded in the source code, because it cannot be
|
|
disabled easily. For outbound authentication, the hard-coded credentials may provide an attacker with
|
|
privileged information or unauthorized access to some other system.
|
|
</p>
|
|
|
|
</overview>
|
|
<recommendation>
|
|
|
|
<p>
|
|
Remove hard-coded credentials, such as user names, passwords and certificates, from source code,
|
|
placing them in configuration files or other data stores if necessary. If possible, store
|
|
configuration files including credential data separately from the source code, in a secure location
|
|
with restricted access.
|
|
</p>
|
|
|
|
<p>
|
|
For outbound authentication details, consider encrypting the credentials or the enclosing data
|
|
stores or configuration files, and using permissions to restrict access.
|
|
</p>
|
|
|
|
<p>
|
|
For inbound authentication details, consider hashing passwords using standard library functions
|
|
where possible. For example, <code>hashlib.pbkdf2_hmac</code>.
|
|
</p>
|
|
|
|
</recommendation>
|
|
<example>
|
|
|
|
<p>
|
|
The following examples shows different types of inbound and outbound authentication.
|
|
</p>
|
|
|
|
<p>
|
|
In the first case, we accept a password from a remote user, and compare it against a plaintext
|
|
string literal. If an attacker acquires the source code they can observe
|
|
the password, and can log in to the system. Furthermore, if such an intrusion was discovered, the
|
|
application would need to be rewritten and redeployed in order to change the password.
|
|
</p>
|
|
|
|
<p>
|
|
In the second case, the password is compared to a hashed and salted password stored in a
|
|
configuration file, using <code>hashlib.pbkdf2_hmac</code>.
|
|
In this case, access to the source code or the assembly would not reveal the password to an
|
|
attacker. Even access to the configuration file containing the password hash and salt would be of
|
|
little value to an attacker, as it is usually extremely difficult to reverse engineer the password
|
|
from the hash and salt.
|
|
</p>
|
|
|
|
<p>
|
|
In the final case, a password is changed to a new, hard-coded value. If an attacker has access to
|
|
the source code, they will be able to observe the new password.
|
|
</p>
|
|
|
|
<sample src="HardcodedCredentials.py" />
|
|
|
|
</example>
|
|
<references>
|
|
|
|
<li>
|
|
OWASP:
|
|
<a href="https://www.owasp.org/index.php/Use_of_hard-coded_password">XSS
|
|
Use of hard-coded password</a>.
|
|
</li>
|
|
|
|
</references>
|
|
</qhelp>
|