Callers Client code can trivially access and modify public non-final static fields. Neither accesses nor modifications can be static fields because access to such fields are not checked by a SecurityManager, and newly set security manager. Furthermore, new values cannot be validated . Furthermore, multiple threads can modify non-final public static data in ways that are not consistent.
Wiki Markup |
---|
Improper use of public static fields can also lead to type safety issues. For example, untrusted code might supply an unexpected subtype when the variable is defined to be of a more general type such as {{java.lang.Object}}. \[[Gong 03|AA. Java References#Gong 03]\] |
Noncompliant Code Example
programmatically before they are stored in these fields.
In the presence of multiple threads, nonfinal public static fields can be modified in inconsistent ways (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.
Noncompliant Code Example
This noncompliant code example is taken from JDK v1.4.2 [FT 2008]. It declares a function table containing a public static field This is an example from the JDK 1.4.2 software \[[Function Table|#ref3]\]. Wiki Markup
Code Block | ||
---|---|---|
| ||
package org.apache.xpath.compiler; public class FunctionTable { public static FuncLoader m_functions; } |
An attacker can replace the function table as follows:
Code Block | bgColor | #FFCCCC
---|
FunctionTable.m_functions = <newnew_table>table; |
Replacing the function table gives the attacker access to the XPathContext
used to evaluate XPath
expressions. The XPathContext
XPathContext
, which is used to set the reference node for evaluating XPath
expressions. Manipulating this XPathContext
can cause unexpected behavior and XML fields can to be modified in inconsistent ways, resulting in unexpected behavior. Also, because static variables are global across the Java Runtime Environment (JRE). They , they can be used as a covert communication channel between different application domains (e.g.for example, through code loaded by different class loaders).
This vulnerability was repaired in JDK v1.4.2_05.
Compliant Solution
Treat public static fields as constants and declare them as final. Consider the use of enum types in the following example.This compliant solution declares the FuncLoader
static field final and treats it as a constant:
Code Block | ||
---|---|---|
| ||
public class MyClass { public static final int LEFT = 1FuncLoader m_functions; // Initialize m_functions in publica static final int RIGHT = 2; } |
The FuncLoader static instance in the noncompliant example could have been declared as final as shown below.
Code Block | ||
---|---|---|
| ||
...
public static final FuncLoader m_functions;
...
|
Compliant Solution
Additionally, for mutable static state one can define assessor methods and add appropriate security checks. Note that this is a different example, wherein the scope of the static variable has been changed to private.
Code Block | ||
---|---|---|
| ||
public class MyClass {
private static byte[] data;
public static byte[] getData() {
return data.clone();
}
public static void setData(byte[] b) {
securityCheck();
data = b.clone();
}
}
|
initialization block
|
Fields declared static and final are also safe for multithreaded use (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 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 rule OBJ01-J. Limit 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;
// ...
}
|
Compliant Solution
This compliant solution declares the serialVersionUID
field final and private:
Code Block | ||
---|---|---|
| ||
class DataSerializer implements Serializable {
private static final long serialVersionUID = 1973473122623778747L;
}
|
The serialization mechanism uses the serialVersionUID
field internally, so accessible wrapper methods are unnecessaryAs a cautionary note however, simply changing the modifier to final may not prevent attackers from indirectly retrieving an incorrect value from the static final variable before its initialization. See MSC00-J. Eliminate class initialization cycles and OBJ03-J. Be careful about final reference for more on this problem.
Risk Assessment
Unauthorized modifications to of public static variables can result in unexpected behavior and can bypass important security checks and/or invoke malicious codeviolation of class invariants. Furthermore, because static variables can be visible to code loaded by different class loaders when those class loaders are in the same delegation chain, such variables can be used as a covert communication channel between different application domains.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|
OBJ31-J
low
probable
medium
P4
L3
References
Wiki Markup |
---|
\[[FT 08|AA. Java References#FT 08]\]
\[[Nisewanger 07|AA. Java References#Nisewanger 07]\] Antipattern 5, Misusing Public Static Variables
\[[SCG 07|AA. Java References#SCG 07]\] Guideline 3.1, Treat public static fields as constants
\[[Gong 03|AA. Java References#Gong 03]\] 9.3 Static Fields |
OBJ10-J | Medium | Probable | Medium | P8 | L2 |
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
CodeSonar | 4.2 | FB.MALICIOUS_CODE.MS_SHOULD_BE_FINAL FB.MALICIOUS_CODE.MS_SHOULD_BE_REFACTORED_TO_BE_FINAL | Field isn't final but should be Field isn't final but should be refactored to be so | ||||||
Eclipse | 1.0 | Implemented. The serializable class .* does not declare a static final serialVersionUID field of type long | |||||||
Coverity | 7.5 | FB.MS_SHOULD_BE_FINAL | Implemented | ||||||
Findbugs | 1.0 | MS_MUTABLE_ARRAY MS_SHOULD_BE_FINAL | Implemented | ||||||
Parasoft Jtest |
| CERT.OBJ10.SPFF CERT.OBJ10.RMO | Inspect 'static' fields which may have intended to be declared 'static final' Avoid referencing mutable fields | ||||||
SonarQube |
| S1444 | "public static" fields should be constant | ||||||
SpotBugs |
| MS_SHOULD_BE_FINAL | Implemented |
Related Guidelines
CWE-493, Critical Public Variable without Final Modifier | |
Guideline 6-10 / MUTABLE-10: Ensure public static final field values are constants |
Bibliography
[FT 2008] | "Function Table" |
Section 9.3, "Static Fields" | |
Antipattern 5, Misusing Public Static Variables | |
Antipattern 5, Misusing Public Static Variables |
...
Field isn't final but should be refactored to be soOBJ03-J. Be careful about final reference 06. Object Orientation (OBJ) OBJ32-J. Do not allow partially initialized objects to be accessed