Page History

...

To mitigate these risks, by default classes should be declared final unless there is a definite need for the class to be extensible. In that case, developers must carefully design the class with extensibility in mind. As a specific instance of this rulerecommendation, classes that are designed to be treated as immutable either must be declared final or must have all of their member methods and fields declared final or private.

In systems where code can come from mixed protection domains, some superclasses might want to permit extension by trusted subclasses while simultaneously preventing extension by untrusted code. Declaring such superclasses to be final is infeasible because it would prevent the required extension by trusted code. One commonly suggested approach is to place code at each point where the superclass can be instantiated to check that the class being instantiated is either the superclass itself or a trustworthy subclass. However, this approach is brittle and is safe only in Java SE 6 or higher (see OBJ11-J. Be wary of letting constructors throw exceptions for a full discussion of the issues involved).

Noncompliant Code Example (BigInteger)

The java.math.BigInteger class is itself an example of noncompliant code. It is nonfinal and consequently extendable, which can be a problem when operating on an instance of BigInteger that was obtained from an untrusted client. For example, a malicious client could construct a spurious mutable BigInteger instance by overriding BigInteger's member functions [Bloch 2008].

...

This code prints: "246", which shows that the value of the supposedly immutable BigInteger bi has been changed.

OBJ01-J. Limit accessibility of fields points out that invariants cannot be enforced for mutable objects. TSM03-J. Do not publish partially initialized objects describes object construction and visibility issues specific to mutable objects, and CON50-J. Do not assume that declaring a reference volatile guarantees safe publication of the members of the referenced object and CON52-J. Document thread-safety and use annotations where applicable discuss some concurrency issues associated with mutable objects.

Violation of this recommendation can be mitigated by treating objects from untrusted sources as potentially malicious subclasses, as directed by OBJ06-J. Defensively copy mutable inputs and mutable internal components. Complying with that rule protects you from the consequences of violating this recommendation.

This example is particularly important because the BigInteger type has several useful cryptographic applications.

Noncompliant Code Example (Security Manager)

This noncompliant code example installs proposes adding a security manager check in the constructor of the java.math.BigInteger class. The security manager denies access when it detects that a subclass without the requisite permissions is attempting to instantiate the superclass [SCG 2009]. It also compares class types, in compliance with OBJ09-J. Compare classes and not class names. Note that this check does not prevent malicious extensions of BigInteger; it instead prevents the creation of BigInteger objects from untrusted code, which also prevents creation of objects of malicious extensions of BigInteger.

package java.math;
 
// ...
 
public class BigInteger {
  public BigInteger(String str) {
    securityManagerCheck(); 

    // ...
  }

  // Check the permission needed to subclass BigInteger
  // throws a security exception if not allowed
  private void securityManagerCheck() {
    // ...
  }
}

Unfortunately, throwing an exception from the constructor of a nonfinal class is insecure because it allows a finalizer attack (see OBJ11-J. Be wary of letting constructors throw exceptions). Furthermore, since BigInteger is Serializable, an attacker could bypass the security check by deserializing a malicious instance of BigInteger. For more information on proper deserialization, see the rule SER04-J. Do not allow serialization and deserialization to bypass the security manager.

Compliant Solution (Final)

This compliant solution prevents creation of malicious subclasses by declaring the immutable java.math.BigInteger class to be final. Although this solution would be appropriate for locally maintained code, it cannot be used in the case of java.math.BigInteger because it would require changing the Java SE API, which has already been published and must remain compatible with previous versions.

package java.math;

// ...

final class BigInteger {
  // ...
}

Compliant Solution (Java SE 6, Public and Private Constructors)

This compliant solution invokes a security manager check as a side effect of computing the Boolean value passed to a private constructor (as seen in OBJ11-J. Be wary of letting constructors throw exceptions). The rules for order of evaluation require that the security manager check must execute before invocation of the private constructor. Consequently, the security manager check also executes before invocation of any superclass's constructor.

This solution prevents the finalizer attack; it applies to Java SE 6 and later versions, where throwing an exception before the java.lang.Object constructor exits prevents execution of finalizers [SCG 2009].

package java.math;

// ...

public class BigInteger {
  public BigInteger(String str) {
    this(str, check());
  }

  private BigInteger(String str, boolean dummy) {
    // Regular construction goes here
  }

  private static boolean check() {
    securityManagerCheck(); 
    return true;
  }
}

Risk Assessment

Permitting a nonfinal class or method to be inherited without checking the class instance allows a malicious subclass to misuse the privileges of the class.

Automated Detection

This rule recommendation is not checkable because it depends on factors that are unspecified in the code, including the invariants upon which the code relies and the necessity of designating a class as extensible, among others. However, simple statistical methods might be useful to find codebases that violate this rule recommendation by checking whether a given codebase contains a higher-than-average number of classes left nonfinal.

Related Guidelines

Bibliography

...

Image Modified Image Modified Image Modified