OBJ03-J. Do not use public static non-final variables

Client code can trivially access public static non-final fields. Neither reads nor writes are checked by a security manager; further, new values cannot be validated programmatically before they are stored in the field. Classes loaded by the same class loaders can access each others' public static members. For example, consider Java applets [[Sun 2008]]:

Normally, if two applets have the same codebase and archive 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. Further, code from any class can access public members of any class that was loaded by any class loader in the delegation chain of the current class's class loader. In the diagram below, for example, code in classes C4 and C5 can freely access public members of class C2, whereas neither class C2 nor class C4 can access public members of class C5.

In the presence of multiple threads, non-final public static fields can be modified in inconsistent ways. (For example, see guideline 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 can supply an unexpected subtype when the variable is defined to be of a more general type, such as java.lang.Object [[Gong 2003]].

Noncompliant Code Example

This noncompliant code example is adopted from JDK v1.4.2 [[FT 2008]]. 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 XPathContext, which 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 (for example, through code loaded by different class loaders).

Note that this vulnerability was repaired in JDK v1.4.2_05.

Compliant Solution

This compliant solution declares the FuncLoader static field 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; see guideline TSM03-J. Do not publish partially initialized objects. However, remember that 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 guideline DCL12-J. Prevent class initialization cycles for more information. Further, individual members of the referenced object can also be changed if the object itself is mutable; see guideline OBJ01-J. Do not assume that declaring a reference to be final causes the referenced object to be immutable.

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 of m_functions to be private; see guideline OBJ00-J. Declare data members as private and provide accessible wrapper methods.

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 final and limits its accessibility to private.

class DataSerializer implements Serializable {
  private static final long serialVersionUID = 1973473122623778747L;
}

The serialization mechanism uses the serialVersionUID field internally, so accessible wrapper methods are unnecessary.

Risk Assessment

Unauthorized modifications of public static variables can result in unexpected behavior and violation of class invariants. Further, 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 in some cases.

Related Guidelines

MITRE CWE: CWE-582 "Array Declared Public, Final, and Static"

MITRE CWE: CWE-493 "Critical Public Variable Without Final Modifier"

MITRE CWE: CWE-500 "Public Static Field Not Marked Final"

[[SCG 2007]] Guideline 3.1, Treat public static fields as constants

Bibliography

[[FT 2008]]
[[Gong 2003]] 9.3 Static Fields
[[Nisewanger 2007]] Antipattern 5, Misusing Public Static Variables
[[Sterbenz 2006]] Antipattern 5, Misusing Public Static Variables

OBJ02-J. Do not ignore return values of methods that operate on immutable objects      Object Orientation (OBJ)      OBJ04-J. Do not allow access to partially initialized objects