Page History

...

This noncompliant code example demonstrates how a malicious subclass Sub can both override the doLogic() method of the superclass and also increase the accessibility of the overriding method. Any user of Sub will be able to can invoke the doLogic method because the base class BadScope defines it to be protected. Class Sub increases the accessibility of doLogic by declaring its own version of the method to be public.

...

Override methods only when necessary. Declare methods and fields final whenever possible to avoid malicious subclassing. When methods and fields cannot be declared final, refrain from increasing the accessibility of overridden methods. (See guideline SEC01-J. Minimize the accessibility of classes and their members.)

class BadScope {
  protected final void doLogic() { // declare as final 
    System.out.println("Super invoked");
    // Do sensitive operations
  }
}

Exceptions

MET17-EX0: According to Sun's Secure Coding Guidelines [[SCG 2007]]

...

For classes that implement the java.lang.Cloneable interface

...

the accessibility of the Object.clone method should be increased from protected to public [SCG 2007.

Risk Assessment

Subclassing allows weakening of access restrictions, which can compromise the security of a Java application.

Automated Detection

StraightforwardDetecting violations of this rule is straightforward.

Related Vulnerabilities

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

...