Wiki Markup |
---|
Callers can trivially access and modify {{public}} {{static}} non-final fields. Neither accesses nor any modifications are checked by a security manager, and newly set values cannot be validated. Classes loaded by the same or different class loaders can access each others' {{public static}} members, unless appropriate protection is installed. For example, consider Java applets \[[Sun 08|AA. Java References#Sun 08]\]: |
Normally, if two applets have the same
codebase
andarchive
parameters, they will be loaded by the same class loader instance. This behavior is required for backward compatibility, and is relied on by several real-world applications. The result is that multiple applets on the same web page may access each others'static
variables at the Java language level, effectively allowing the multiple applets to be written as though they comprised a single application.
However, applets loaded by different class loader instances are completely isolated and cannot access each others' public static
Client code can trivially access public static fields 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 (for example, see CON14TSM01-J. Do not let the ( this ) reference escape during object constructionfor an example).unmigrated-wiki-markup
Improper use of {{ public static }} fields can also result in type -safety issues. For example, untrusted code may 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 03|AA. Java References#Gong 03]\] [Gong 2003]. As a result, classes must not contain nonfinal public static fields.
Noncompliant Code Example
...
This noncompliant code example is adopted taken from JDK v1.4.2 \ [[FT 08|AA. Java References#FT 08]\]. It declares a function table containing a {{public static}} FT 2008]. It declares a function table containing a public static field.
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 |
---|
FunctionTable.m_functions = <newnew_table>table; |
Replacing the function table gives the attacker access to the XPathContext
. The XPathContext
, which is used to set the reference node for evaluating XPath
expressions. Manipulating it XPathContext
can allow 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 (e.g.for example, through code loaded by different class loaders).
This vulnerability was repaired in JDK v1.4.2_05.
Compliant Solution
This compliant solution declares the FuncLoader
static field as final and treats it like as a constant.:
Code Block | ||
---|---|---|
| ||
public static final FuncLoader m_functions; // Initialize m_functions in a constructorstatic initialization block |
Fields declared static and final are also safe for multithreaded use (CON26see TSM03-J. Do not publish partially initialized objects for more information). On a cautionary note, however, However, remember that simply changing the modifier to final
may might not prevent attackers from indirectly retrieving an incorrect value from the static final variable before its initialization (see MSC07DCL00-J. Eliminate Prevent class initialization cyclesfor more information). Individual Furthermore, individual members of the referenced object can also be changed if it is mutable (see OBJ01-J. Be aware that a final reference may not always refer to immutable data)the object itself is mutable.
It is also permissible to use a wrapper method to retrieve the value of m_functions
. This has encapsulation advantages as it restricts its accessibility to , allowing m_functions
to be declared private (see OBJ00rule OBJ01-J. Declare data members as private and provide accessible wrapper methods). However, it is unnecessary when m_functions
needs to be treated like a world-accessible constant.Limit accessibility of fields for more information).
Noncompliant Code Example (serialVersionUID
)
This noncompliant code example uses a public static non-final 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 as final and limits its accessibility to private.:
Code Block | ||
---|---|---|
| ||
class DataSerializer implements Serializable {
private static final long serialVersionUID = 1973473122623778747L;
}
|
The serialization mechanism internally uses the serialVersionUID
field internally, so no accessible wrapper methods are requiredunnecessary.
Risk Assessment
Unauthorized modifications of public static variables can result in unexpected behavior and violation 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 |
---|
OBJ10-J |
Medium |
Probable |
Medium | P8 | L2 |
References
Wiki Markup |
---|
\[[FT 08|AA. Java References#FT 08]\]
\[[Sterbenz 06|AA. Java References#Sterbenz 06]\] Antipattern 5, Misusing Public Static Variables
\[[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
\[[MITRE 09|AA. Java References#MITRE 09]\] [CWE ID 582|http://cwe.mitre.org/data/definitions/582.html] "Array Declared Public, Final, and Static", [CWE ID 493|http://cwe.mitre.org/data/definitions/493.html] "Critical Public Variable Without Final Modifier", [CWE ID 500|http://cwe.mitre.org/data/definitions/500.html] "Public Static Field Not Marked Final" |
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 soOBJ02-J. Do not ignore return values of methods that operate on immutable objects 08. Object Orientation (OBJ) OBJ04-J. Do not allow partially initialized objects to be accessed