...
- The sensitive information can become accessible to whoever has access to the source code, for example, the developers.
- Once the system goes into production, it can become unwieldy to manage and accommodate changes to the code.
- In certain cases, it can also violate the fundamental principle of recalling the memory used to store the sensitive information as soon as the required operation has concluded. A carefully administered heap dump or application monitoring through a JVM debugger can expose the sensitive information if it persists over an extended period of time.
- Malicious users may use decompilation techniques to resurrect the hardcoded sensitive information. This is a critical security vulnerability.
Noncompliant Code Example
This noncompliant code example uses a password field instantiated as a String.
...
| Code Block |
|---|
Compiled from "Hardcoded.java"
class Hardcoded extends java.lang.Object{
java.lang.String password;
Hardcoded();
Code:
0: aload_0
1: invokespecial #1; //Method java/lang/Object."<init>":()V
4: aload_0
5: new #2; //class java/lang/String
8: dup
9: ldc #3; //String guest
11: invokespecial #4; //Method java/lang/String."<init>":(Ljava/lang/String;)V
14: putfield #5; //Field password:Ljava/lang/String;
17: return
public static void main(java.lang.String[]);
Code:
0: return
}
|
Compliant Solution
This compliant solution uses a char array to store the password after it is retrieved from an external file. The password is immediately cleared out after use. This limits the exposure time.
| Code Block | ||
|---|---|---|
| ||
class Password {
public static void main(String[] args) throws IOException {
char[] password = new char[100];
BufferedReader br = new BufferedReader(new InputStreamReader(
new FileInputStream("password.txt")));
// reads the password into the char array, returns the number of bytes read
int n = br.read(password);
// decrypt password, perform operations
for(int i= n - 1;i >= 0;i--) // manually clear out the password immediately after use
password[i] = 0;
br.close();
}
}
|
Risk Assessment
Hardcoding sensitive information can lead to critical security vulnerabilities.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
FIO36-J | high | probable | medium | P12 | L1 |
Automated Detection
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
| Wiki Markup |
|---|
\[[Gong 03|AA. Java References#Gong 03]\] 9.4 Private Object State and Object Immutability \[[MITRE 09|AA. Java References#MITRE 09]\] [CWE ID 259|http://cwe.mitre.org/data/definitions/259.html] "Hard-Coded Password" |
...