Page History

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, it is desired that only trusted implementations be allowed to extend the class. Declaring the class final proves to be a very stringent alternative in this case. In such cases, the class must be carefully designed for inheritance.

Another related pitfall occurs when malicious classes are allowed to extend from a non-final class. 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.

A nonfinal class or method that is not meant to be inherited can be overridden by an attacker if it is not declared as {{final}} \[[McGraw 00|java:AA. Java References#McGraw 00]\] Chapter [Seven|http://www.securingjava.com/chapter-seven/chapter-seven-1.html] Rule 3: "Make Everything Final, Unless There's a Good Reason Not To".

If inheritance is to be limited to trusted implementations for a public, nonfinal class, then the class type should be confirmed before creating the instance at each place where an instance of the nonfinal class can be created. A SecurityManager check should be enforced on detecting a subclass (Chapter 6 of \[[Gong 03|java:AA. Java References#Gong 03]\]).

At all points that 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', a security manager check must be performed to ensure that malicious classes cannot misuse the class.

The use of A nonfinal class can be subverted simply by declaring a malicious class that inherits from the nonfinal class, which implies that there is no need for reflection. However, reflection is necessary if the nonfinal class is non-final class 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, an attacker can easily create an instance and override methods of class BankOperation. This example also assumes the absence of appropriate Security Manager checksa malicious class can extend the public non-final class, NonFinal. As a result, it can call any of its instance methods and access its protected fields.

public class BankOperation {


//The account balance has already been retrieved from the database and stored in the foll variable
  private Integer balance = 5000;

NonFinal {
  public BankOperationNonFinal() {

    //invoke java.lang.Object.getClass to get class instance
  }
}

Compliant Solution

This compliant 

...

solution 

...

installs 

...

a security manager check in the 

...

constructor of the 

...

non-final class. Access is denied if it is detected that a subclass is trying to instantiate the superclass. Only if the subclass has the requisite permissions, will it be able to proceed. \[[SCG 07|java:AA. Java References#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 NonFinal
      securityManagerCheck();
    }
  // ...   
  

Compliant Solution

This compliant solution limits the extensibility of the sensitive class by using the final keyword.

final class BankOperation{
//...
}

In case the class needs to be extended, permissions should be checked in case a subclass is detected during construction so that malicious implementations are blocked.

Compliant Solution

Preferring static factory methods over {{public}} or {{protected}} constructors also helps limit class extensibility \[[Bloch 08|java:AA. Java References#Bloch 08]\]. Typically, a {{private}} constructor is explicitly provided to override the default no-argument {{public}} constructor.

class BankOperation {
  private BankOperation() {
    // ...
  }
  public static void factoryMethod() {
    // ...
  }
}

Compliant Solution

A third solution is to provide a non-empty private constructor accessible only from within the class. This solution is not susceptible to reflection based attacks originating from unprivileged code since the AccessibleObject.setAccessible() method requires a security manager check by default.

class BankOperation {
  private BankOperation() {
    // ...
  }
}

Risk Assessment

Allowing a nonfinal non-final class or method to be inherited without checking the class instances allows an attacker to exploit itinstance allows a malicious subclass to misuse the privileges of the class.

...

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

...