Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Parasoft Jtest 2021.1

Wiki MarkupIncreasing the accessibility of overridden or hidden methods permits a malicious subclass to offer wider access to the restricted method than was originally intended. Consequently, programs must override methods only when necessary and must declare methods final whenever possible to prevent malicious subclassing. When methods cannot be declared final, programs must refrain from increasing the accessibility of overridden methods.

The access modifier of an overriding or hiding method must provide at least as much access as the overridden or hidden method (The Java Language Specification, §8 intended. The access modifier of an overriding or hiding method must provide at least as much access as the overridden or hidden method \[[JLS 2005|AA. Bibliography#JLS 05]\], Section 8.4.8.3, "Requirements in Overriding and Hiding" [JLS 2015]). The following are table lists the allowed accesses:.

Overridden/

hidden method modifier

Hidden Method Modifier

Overriding/

hiding method modifier

Hiding Method Modifier

public

public

protected

protected or public

default

default or protected or public

private

Cannot be overridden

Noncompliant Code Example

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 Super defines it to be protected. Class Sub increases , consequently allowing class Sub to increase the accessibility of doLogic() by declaring its own version of the method to be public.

Code Block
bgColor#FFcccc

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

public class Sub extends BadScopeSuper {
  public void doLogic() { 
    System.out.println("Sub invoked");
    // Do sensitive operations
  }
}

Compliant Solution

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.)This compliant solution declares the doLogic() method final to prevent malicious overriding:

Code Block
bgColor#ccccff

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

Noncompliant Code Example

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

According to Sun's Secure Coding Guidelines [[SCG 2007]]

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.

Code Block
bgColor#FFcccc

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.

Code Block
bgColor#ccccff

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

It is recommended but not mandatory to limit the accessibility of a subclass's constructor to that of the superclass's constructor.

Exceptions

SPC01-EX1: According to Sun's Secure Coding Guidelines [[SCG 2007]]

...

Exceptions

MET04-J-EX0: For classes that implement the java.lang.Cloneable interface

...

, the accessibility of the Object.clone() method should be increased from protected to public [SCG 2009].

Risk Assessment

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

Recommendation

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

MET17

MET04-J

medium

Medium

probable

Probable

medium

Medium

P8

L2

Automated Detection

Straightforward.

Related Vulnerabilities

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

Detecting violations of this rule is straightforward.

ToolVersionCheckerDescription
Parasoft Jtest
Include Page
Parasoft_V
Parasoft_V
CERT.MET04.OPMDo not override an instance "private" method

Related Guidelines

...

...

, Reliance on Package-

...

Level Scope

Secure Coding Guidelines for Java SE, Version 5.0

Guideline 4-1 / EXTEND-1: Limit the accessibility of classes, interfaces, methods, and fields

Bibliography

...

...

[

...

...

...

...

...

...

...


...

Image Added Image Added Image AddedMET15-J. Do not use deprecated or obsolete classes or methods      05. Methods (MET)      MET18-J. Avoid using finalizers