Callers Client code can trivially access and modify public non-final static fields. Neither accesses nor modifications can be static fields because access to such fields are not checked by a SecurityManager, and newly set values can not be validated. Furthermore multiple threads can modify non-final public static data in ways that are not consistent.

Noncompliant code example

security manager. Furthermore, new values cannot be validated programmatically before they are stored in these fields.

In the presence of multiple threads, nonfinal public static fields can be modified in inconsistent ways (see TSM01-J. Do not let the this reference escape during object construction for an example).

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]. As a result, classes must not contain nonfinal public static fields.

Noncompliant Code Example

This noncompliant code example is taken from JDK v1.4.2 [FT 2008]. It declares a function table containing a public static fieldThis is an example from the JDK 1.4.2 software.

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 the XPathContext, which is used to evaluate XPath expression. Static 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 a Java runtime environment. They the Java Runtime Environment (JRE), they can be used as a covert communication channel between different application domains (e.g. by for example, through code loaded into by different class loaders).

Compliant Solution

There are several strategies one can adopt to tackle this problem.

This vulnerability was repaired in JDK v1.4.2_05.

Compliant Solution

This compliant solution declares the FuncLoader static field final and treats it as a constant:1. Treat public static fields as constants and declare them as final. Consider the use of enum types.

public class MyClass {
    public static final int LEFT = 1FuncLoader m_functions;
// Initialize m_functions in publica static final int RIGHT = 2;
}

2. Reduce the scope of static fields. This ensures access only by legitimate public member functions which can then use SecurityManager to validate access to the static field.

package org.apache.xpath.compiler;

public class FunctionTable {
    private static FuncLoader m_functions;
}

initialization block

Fields declared static and final are also safe for multithreaded use (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 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.

It is also permissible to use a wrapper method to retrieve the value of m_functions, allowing m_functions to be declared private (see rule OBJ01-J. Limit accessibility of fields for more information).

Noncompliant Code Example (serialVersionUID)

This noncompliant code example uses a public static 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 private:3. Define assessor methods for mutable static state. Add appropriate security checks.

public class MyClassDataSerializer {

    private static byte[] data;
    public static byte[] getData() {
        return data.clone();
    }

    public static void setData(byte[] b) {
        securityCheck();
       data = b.clone();
    }
}

Risk Assessment

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.

References
Avoiding Antipatterns Antipattern 5, Misusing Public Static Variables

Java Secure Coding Guidelines Section 3.1, Treat public static fields as constants

Automated Detection

Related Guidelines

Bibliography

...

Image Added Image Added Image Added

Field isn't final but should be refactored to be soFunction Table Field detail, public static FuncLoader m_functions