Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Edited by NavBot

Callers can trivially access and modify public static non-final fields. Neither accesses nor any modifications are automatically checked by a security manager, and newly set values cannot be validated. Furthermore, multiple threads can modify non-final public static fields in inconsistent ways.

Wiki Markup
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|AA. Java References#Gong 03]\]

Noncompliant Code Example

Wiki Markup
This noncompliant code example is adopted from JDK v1.4.2 \[[FT 08|AA. Java References#FT 08]\]. It declares a function table containing a {{public static}} field.

Code Block
bgColor#FFCCCC
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 = <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.

Code Block
bgColor#ccccff
public static final FuncLoader m_functions;

As 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 and OBJ01-J. Be aware that a final reference may not always refer to immutable data for more details about such problems.

Noncompliant Code Example

This noncompliant code example uses a public static non-final serialVersionUID field in a class designed for serialization.

Code Block
bgColor#FFCCCC
public static long serialVersionUID = 1973473122623778747L;

Compliant Solution

This compliant solution declares the serialVersionUID field as final and limits its accessibility to private.

Code Block
bgColor#ccccff
private static final long serialVersionUID = 1973473122623778747L;

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

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"


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