OBJ05-J. Limit the extensibility of non-final classes and methods to only trusted subclasses

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

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

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 NonFinal
      securityManagerCheck(); // throws a security exception if not allowed
    }
  // ...   
  }
}

However, throwing an exception from the constructor is a non-final class is insecure because it allows a finalizer attack. (See guideline OBJ04-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

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.

public class NonFinal {
  public NonFinal() {
    this(securityManagerCheck()); // throws a security exception if not allowed
    // ...
  }
  
  private NonFinal(boolean securityManagerCheck) {
    // No statements required	  
  }

  private static boolean securityManagerCheck() {
    // Perform security check	  
  }
}

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]] Chapter Seven Rule 3: "Make Everything Final, Unless There's a Good Reason Not To"
[[Lai 2008]]
[[SCG 2007]] Guideline 1-2 "Limit the extensibility of classes and methods"
[[Gong 2003]] Chapter 6: "Enforcing Security Policy"
[[Bloch 2008]] Item 1: "Consider static factory methods instead of constructors"

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