Hard coding sensitive information, such as passwords, server IP addresses, and encryption keys can expose the information to attackers. Anyone who has access to the class files can decompile them and discover the sensitive information. Leaking data protected by International Traffic in Arms Regulations (ITAR) or the Health Insurance Portability and Accountability Act (HIPAA) can also have legal consequences. Consequently, programs must not hard code sensitive information.
Hard coding sensitive information also increases the need to manage and accommodate changes to the code. For example, changing a hard-coded password in a deployed program may require distribution of a patch [Chess 2007].
Noncompliant Code Example
This noncompliant code example includes a hard-coded server IP address in a constant
A malicious user can use the
javap -c IPaddress command to disassemble the class and discover the hard-coded server IP address. The output of the disassembler reveals the server IP address
172.16.254.1 in clear text:
This compliant solution retrieves the server IP address from an external file located in a secure directory, as recommended by FIO00-J. Do not operate on files in shared directories. It reads the file in compliance with FIO10-J. Ensure the array is filled when using read() to fill an array. Exposure of the IP address is further limited by storing it in a char array rather than a
java.lang.String, and by clearing the server IP address from memory immediately after use.
To further limit the exposure time of the sensitive server IP address, replace
BufferedReader with a direct native input/output (NIO) buffer, which can be cleared immediately after use.
Noncompliant Code Example (Hard-Coded Database Password)
The user name and password fields in the SQL connection request are hard coded in this noncompliant code example:
Note that the one- and two-argument
java.sql.DriverManager.getConnection() methods can also be used incorrectly.
This compliant solution reads the user name and password from a configuration file located in a secure directory:
It is also permissible to prompt the user for the user name and password at runtime.
When possible, sensitive information such as passwords should be stored in character arrays rather than strings because the Java Virtual Machine may retain strings long after they are no longer needed. However, this example uses strings because
DriverManager.getConnection() requires them.
Hard coding sensitive information exposes that information to attackers. The severity of this rule can vary depending on the kind of information that is disclosed. Frequently, the information disclosed is password or key information, which can lead to remote exploitation. Consequently, a high severity rating is given but may be adjusted downwards according to the nature of the sensitive data.
Hardcoded constant database password
Empty database password
|Parasoft Jtest||10.3||SECURITY.WSC.HCCS, SECURITY.WSC.HCCK, SECURITY.WSC.AHCA||Implemented|
GERONIMO-2925 describes a vulnerability in the WAS CE tool, which is based on Apache Geronimo. It uses the Advanced Encryption Standard (AES) to encrypt passwords but uses a hard-coded key that is identical for all the WAS CE server instances. Consequently, anyone who can download the software is provided with the key to every instance of the tool. This vulnerability was resolved by having each new installation of the tool generate its own unique key and use it from that time on.
Hard-coded Password [XYP]
Android Implementation Details
Hard-coded information can be easily obtained on Android by using the
apktool to decompile an application or by using
dex2jar to convert a dex file to a jar file.
Section 11.2, "Outbound Passwords: Keep Passwords out of Source Code"
"Unsafe Mobile Code: Database Access"
Section 9.4, "Private Object State and Object Immutability"