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]]:
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
fields.
In the presence of multiple threads non-final public static
fields can be modified in inconsistent ways (for example, see TSM01-J. Do not let the (this) reference escape during object construction).
Improper use of public static
fields can also result in type safety issues. For example, untrusted code may supply an unexpected subtype when the variable is defined to be of a more general type such as java.lang.Object
. [[Gong 03]]
Noncompliant Code Example
This noncompliant code example is adopted from JDK v1.4.2 [[FT 08]]. It declares a function table containing a public static
field.
package org.apache.xpath.compiler; public class FunctionTable { public static FuncLoader m_functions; }
An attacker can replace the function table as follows.
FunctionTable.m_functions = <new_table>;
Replacing the function table gives the attacker access to the XPathContext
. The XPathContext
is used to set the reference node for evaluating XPath
expressions. Manipulating it can allow 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., through code loaded by different class loaders).
Compliant Solution
This compliant solution declares the FuncLoader
static
field as final
and treats it like a constant.
public static final FuncLoader m_functions; // Initialize m_functions in a constructor
Fields declared static final
are also safe for multithreaded use (TSM03-J. Do not publish partially initialized objects). On 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 MSC07-J. Eliminate class initialization cycles). 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).
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 private
(see OBJ00-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.
Noncompliant Code Example (serialVersionUID
)
This noncompliant code example uses a public static
non-final serialVersionUID
field in a class designed for serialization.
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
.
class DataSerializer implements Serializable { private static final long serialVersionUID = 1973473122623778747L; }
The serialization mechanism internally uses the serialVersionUID
field so no accessible wrapper methods are required.
Risk Assessment
Unauthorized modifications of public static
variables can result in unexpected behavior and violation of class invariants.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
OBJ03- J |
medium |
probable |
medium |
P8 |
L2 |
References
[[FT 08]]
[[Sterbenz 06]] Antipattern 5, Misusing Public Static Variables
[[Nisewanger 07]] Antipattern 5, Misusing Public Static Variables
[[SCG 07]] Guideline 3.1, Treat public static fields as constants
[[Gong 03]] 9.3 Static Fields
[[MITRE 09]] CWE ID 582 "Array Declared Public, Final, and Static", CWE ID 493 "Critical Public Variable Without Final Modifier", CWE ID 500 "Public Static Field Not Marked Final"
OBJ02-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