SCP01-J. Declare sensitive methods private or final, fields private and final, and classes to be final

According to [JLS Section 8.4.8.3, Requirements in Overriding and Hiding]:

"The access modifier of an overriding or hiding method must provide at least as much access as the overridden or hidden method, or a compile-time error occurs."

The allowed accesses are:

This also means that there is potential for some functionality having a restrictive modifier to be overridden by a less restrictive modifier.

Noncompliant Code Example

This noncompliant code example exemplifies how a malicious subclass Sub can override the doLogic method of the super class. Any user of Sub will be able to invoke the doLogic method since the base class BadScope defined it with the protected access modifier. The class Sub can allow more access than BadScope by using the public modifier.

class BadScope {
  protected void doLogic() { System.out.println("Super invoked"); }
}

public class Sub extends BadScope {
  public void doLogic() { 
    System.out.println("Sub invoked");
    //do restrictive operations
  }
}

Compliant Solution

Do not override a method unless absolutely necessary. Declare all methods and fields final to avoid malicious subclassing. This is in compliance with the tenets of OBJ31-J. Do not use public static non-final variables and OBJ00-J. Declare data members private.

class BadScope {
  private final void doLogic() { System.out.println("Super invoked"); }
}

Noncompliant Code Example

This noncompliant code example overrides the finalize() method of the superclass Base, and changes its accessibility from protected to public.

According to Sun's Secure Coding Guidelines [[SCG 07]]:

In addition, refrain from increasing the accessibility of an inherited method, as doing so may break assumptions made by the superclass. A class that overrides the protected java.lang.Object.finalize method and declares that method public, for example, enables hostile callers to finalize an instance of that class, and to call methods on that instance after it has been finalized. A superclass implementation unprepared to handle such a call sequence could throw runtime exceptions that leak private information, or that leave the object in an invalid state that compromises security. One noteworthy exception to this guideline pertains to classes that implement the java.lang.Cloneable interface. In these cases, the accessibility of the Object.clone method should be increased from protected to public.

final class SubClass extends Base {
  public void finalize() {
    // ...
  }
}

Compliant SOlution

This compliant solution correctly declares the finalize() method protected. It is not possible to further limit the accessibility as Object's finalize method itself is declared protected.

final class SubClass extends Base {
  protected void finalize() {
    // ... 
  }
}

Risk Assessment

Subclassing allows access restrictions to be weakened, possibly compromising the security of a Java application.

Automated Detection

TODO

Related Vulnerabilities

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

References

[[JLS 05]] Section 8.4.8.3, Requirements in Overriding and Hiding
[[MITRE 09]] CWE ID 487 "Reliance on Package-level Scope"

SCP00-J. Use as minimal scope as possible for all variables and methods      04. Scope (SCP)      SCP02-J. Do not expose private members of the outer class from within a nested class