Page History

Java classes and methods may have invariants. An invariant is a property that is assumed to be true at certain points during program execution but is not formally specified as true. Invariants may be used in assert statements or may be informally specified in comments.

Method invariants can include guarantees made about what the method can do, requirements about the state of the object when the method is invoked, or guarantees about the state of the object when the method completes. For example, a method of a Date class might guarantee that 1 <= day_of_month <= 31 when the method exits.  

Class invariants are guarantees made about the state of their objects' fields upon the completion of any of their methods. For example, classes whose member fields may not be modified once they have assumed a value are called immutable classes. An important consequence of immutability is that the invariants of instances of these classes are preserved throughout their lifetimes.

Similarly, classes can rely on invariants to properly implement their public interfaces. These invariants might relate to the state of member fields or the implementation of member methods. Generally, classes can rely on encapsulation to help maintain these invariants, for example, by making member fields private. However, encapsulation can be incompatible with extensibility. For example, a class designer might want a method to be publicly accessible yet rely on the particulars of its implementation when using it in another method within the class. In this case, overriding the method in a subclass can break the internal invariants of the class.  Extensibility consequently carries with it two significant risks: a subclass can fail to satisfy the invariants promised to clients by its superclass, and it can break the internal invariants on which the superclass relies. For example, an immutable class that lacks the final qualifier can be extended by a malicious subclass that can modify the state of the supposedly immutable object. Furthermore, a malicious subclass object can impersonate the immutable object while actually remaining mutable. Such malicious subclasses can violate program invariants on which clients depend, consequently introducing security vulnerabilities. Note that the same can be said for a benign subclass that mistakenly supports mutability. These risks relate to both benign and malicious development.

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 recommendation, 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].

The following code example demonstrates such an attack:

// Malicious subclassing of java.math.BigInteger
class BigInteger extends java.math.BigInteger {
  private byte[] ba;

  public BigInteger(String str) {
    super(str);
    ba = (new java.math.BigInteger(str)).toByteArray();
  }

  public BigInteger(byte[] ba) {
    super(ba);
    this.ba = ba;
  }

  public void setValue(byte[] ba) {
    this.ba = ba;
  }

  @Override public byte[] toByteArray() {
    return ba;
  }
}

Unlike the benign BigInteger class, this malicious BigInteger class is clearly mutable because of the setValue() method. Any code that receives an object of this class and assumes that the object is immutable will behave unexpectedly, as shown by the following code:

BigInteger bi = new BigInteger("123");

bi.setValue((new BigInteger("246")).toByteArray());

System.out.println(new BigInteger(bi.toByteArray()));  

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 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(); 

    // ...
  }

  

A non-final class or method that is not meant to be inherited can be overridden by an attacker if it is not declared final. Sometimes, only trusted implementations should be allowed to extend the class. Because declaring the class final is overly prohibitive in such cases, it must be carefully designed for inheritance.

Consider two classes belonging to different protection domains. One of them is malicious whereas the other is trusted. If the malicious class extends the trusted {{public}} non-final class and inherits without overriding a method of the trusted class, the fully qualified invocation of the malicious class's version of the method uses the protection domain of the trusted class. In this case, the trusted class's permissions are examined to execute the method \[[Gong 2003|AA. Bibliography#Gong 03]\].

One suggestion is that at all points where the class can be instantiated, there must be checks to ensure that the instance being created has the same type as the class. If the type is found to be that of a subclass instead of the non-final public superclass's type, a security manager check can be performed to ensure that malicious classes cannot misuse the class. This approach is insecure because it allows a malicious class to add a finalizer and obtain a partially initialized instance of the class. (See guideline OBJ04-J. Do not allow access to partially initialized objects.) For non-final classes, the method that performs the security manager check must be passed as an argument to a private constructor so that Object's constructor does not exit before the security check is performed.

The use of reflection is necessary to exploit the non-final class if it has members that are declared private or are otherwise inaccessible to the attacker. Declaring the class or its methods final prohibits this level of access.

Noncompliant Code Example

In this noncompliant code example, a malicious class can extend the public non-final class, NonFinal. As a result, it can call any of its accessible instance methods and access its protected fields.

public class NonFinal {
  public NonFinal() {
    // ...   
  }
}

Noncompliant Code Example

This noncompliant code example installs a security manager check in the constructor of the non-final class. Access is denied if the security manager detects that a subclass without the requisite permissions, is trying to instantiate the superclass \[[SCG 2007|AA. Bibliography#SCG 07]\].

public class NonFinal {
  public NonFinal() {
    // Invoke java.lang.Object.getClass to get class instance
    Class c = getClass();
    // Confirm class type
    if (c != NonFinal.class) {
      // Check the permission needed to subclass NonFinalBigInteger
      securityManagerCheck(); // throws a security exception if not allowed
  private void }securityManagerCheck() {
    // ...   
  }
}

HoweverUnfortunately, throwing an exception from the constructor is of a non-final nonfinal class is insecure because it allows a finalizer attack . (See guideline OBJ04(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 access to partially initialized objects.)

This noncompliant code example complies with guideline OBJ06-J. Compare classes and not class names because it compares class types and not class names.

Compliant Solution

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]Irrespective of whether it is a trusted instance or an untrusted one, install a security manager check using the technique described in guideline OBJ04-J. Do not allow access to partially initialized objects.

package java.math;

// ...

public class NonFinalBigInteger {
  public NonFinalBigInteger(String str) {
    this(securityManagerCheckstr, check()); // throws a security exception if not allowed
    // ...
  }
  
  private NonFinalBigInteger(String str, boolean securityManagerCheckdummy) {
    // NoRegular statementsconstruction required	goes  here
  }

  private static boolean securityManagerCheckcheck() {
     // Perform security check	  securityManagerCheck(); 
    return true;
  }
}

Risk Assessment

Allowing a non-final class or method to be inherited without checking the class instance allows a malicious subclass to misuse the privileges of the class.

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this guideline on the CERT website

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this guideline on the CERT website.

Bibliography

\[[McGraw 2000|AA. Bibliography#McGraw 00]\] Chapter Seven Rule 3: "Make Everything Final, Unless There's a Good Reason Not To"
\[[Lai 2008|AA. Bibliography#Lai 08]\]
\[[SCG 2007|AA. Bibliography#SCG 07]\] Guideline 1-2 "Limit the extensibility of classes and methods"
\[[Gong 2003|AA. Bibliography#Gong 03]\] Chapter 6: "Enforcing Security Policy"
\[[Bloch 2008|AA. Bibliography#Bloch 08]\] Item 1: "Consider static factory methods instead of constructors"

Automated Detection

This 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 recommendation by checking whether a given codebase contains a higher-than-average number of classes left nonfinal.

Related Guidelines

Bibliography

...

Image Added Image Added Image AddedOBJ04-J. Do not allow access to partially initialized objects      08. Object Orientation (OBJ)      OBJ06-J. Compare classes and not class names