Page History

Client code can trivially access public static fields . Neither reads nor writes because access to such variables 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 guideline "see TSM01-J. Do not let the ( this ) reference escape during object construction" for an example).)unmigrated-wiki-markup

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|AA. Bibliography#Gong 03]\]]. As a result, classes must not contain nonfinal public static fields.

Noncompliant Code Example

Wiki MarkupThis noncompliant code example is adopted taken from JDK v1.4.2 \ [[FT 2008|AA. Bibliography#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 = <newnew_table>table;

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).

Note that this 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 as a constant.:

public static final FuncLoader m_functions;
// Initialize m_functions in a static initialization constructorblock

Fields declared static and final are also safe for multithreaded use . (See guideline "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 guideline "DCL12(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. (See guideline "OBJ02-J. Never conflate immutability of a reference with that of the referenced object.")

It is also permissible to use a wrapper method to retrieve the value of m_functions. This has encapsulation advantages because it permits , allowing m_functions to be declared private . See guideline "(see rule OBJ01-J. Declare data members as private and provide accessible wrapper methods" 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.:

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. 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 in some cases.

Related Guidelines

[MITRE CWE|http://cwe.mitre.org/]: [CWE-582|http://cwe.mitre.org/data/definitions/582.html] "Array Declared Public, Final, and Static," [CWE-493|http://cwe.mitre.org/data/definitions/493.html] "Critical Public Variable Without Final Modifier," and [CWE-500|http://cwe.mitre.org/data/definitions/500.html] "Public Static Field Not Marked Final"
\[[SCG 2007|AA. Bibliography#SCG 07]\] Guideline 3.1, Treat public static fields as constants

Bibliography

\[[FT 2008|AA. Bibliography#FT 08]\] Function Table Class Function Table
\[[Gong 2003|AA. Bibliography#Gong 03]\] 9.3 Static Fields
\[[Nisewanger 2007|AA. Bibliography#Nisewanger 07]\] Antipattern 5, Misusing Public Static Variables
\[[Sterbenz 2006|AA. Bibliography#Sterbenz 06]\] Antipattern 5, Misusing Public Static Variables

Automated Detection

Related Guidelines

Bibliography

...

Image Added Image Added Image Added

Field isn't final but should be refactored to be soOBJ03-J. Sensitive classes must not let themselves be copied      04. Object Orientation (OBJ)      OBJ05-J. Do not allow access to partially initialized objects