Client code can trivially access public static fields as because access to such fields are not checked by a security manager. Furthermore, new values cannot be validated programmatically before they are stored in these fields.
In the presence of multiple threads, non-final nonfinal public static fields can be modified in inconsistent ways . See rule (see TSM01-J. Do not let the this reference escape during object construction for an example).
Improper use of public static fields can also result in type-safety issues. For example, untrusted code can supply an unexpected subtype with malicious methods when the variable is defined to be of a more general type, such as java.lang.Object
[Gong 2003]. As a result, classes must not contain nonfinal public static fields.
...
This noncompliant code example is adopted taken from JDK v1.4.2 [FT 2008]. It declares a function table containing a public static field.
...
Replacing the function table gives the attacker access to XPathContext
, which is used to set the reference node for evaluating XPath
expressions. Manipulating XPathContext
can cause XML fields to be modified in inconsistent ways, resulting in unexpected behavior. Also, because static variables are global across the Java Runtime Environment (JRE), they can be used as a covert communication channel between different application domains (for example, through code loaded by different class loaders).
This vulnerability was repaired in JDK v1.4.2_05.
...
This compliant solution declares the FuncLoader
static field final
and treats it as a constant.:
Code Block | ||
---|---|---|
| ||
public static final FuncLoader m_functions; // Initialize m_functions in a static initialization block |
Fields declared static
and final
are also safe for multithreaded use . (See rule [see TSM03-J. Do not publish partially initialized objects for more information). ) However, remember that simply changing the modifier to final
might not prevent attackers from indirectly retrieving an incorrect value from the static final variable before its initialization . (See rule see DCL00-J. Prevent class initialization cycles for more information). ) Furthermore, individual members of the referenced object can also be changed if the object itself is mutable.
It is also permissible to use a wrapper method to retrieve the value of m_functions
, allowing m_functions
to be declared private
. See (see rule OBJ01-J. Declare data members as private and provide accessible wrapper methodsLimit accessibility of fields for more information).
Noncompliant Code Example (serialVersionUID
)
This noncompliant code example uses a public static nonfinal serialVersionUID
field in a class designed for serialization.:
Code Block | ||
---|---|---|
| ||
class DataSerializer implements Serializable { public static long serialVersionUID = 1973473122623778747L; // ... } |
...
This compliant solution declares the serialVersionUID
field final and private.:
Code Block | ||
---|---|---|
| ||
class DataSerializer implements Serializable { private static final long serialVersionUID = 1973473122623778747L; } |
...
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
OBJ10-J | Medium | Probable | Medium | P8 | L2 |
Automated Detection
Tool | Version | Checker | Description | |
---|---|---|---|---|
Eclipse | 1.0 | Implemented. The serializable class .* does not declare a static final serialVersionUID field of type long long | Implemented | |
Coverity | 7.5 | FB.MS_SHOULD_BE_FINAL | Implemented | |
Findbugs | 1.0 | MS_MUTABLE_ARRAY MS_SHOULD_BE_FINAL | Implemented |
Related Guidelines
CWE-493. , Critical public variable without final modifier Public Variable without Final Modifier | |
Secure Coding Guidelines for the Java Programming Language, Version 3.0 | Guideline 3-1. Treat public static fields as constants |
Bibliography
[FT 2008] | Function Table, |
Section 9.3, "Static Fields" | |
Antipattern 5, Misusing Public Static Variables | |
Antipattern 5, Misusing Public Static Variables |
...