Page History

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

Wiki Markup
According to \[[JLS Section 8.4.8.3, Requirements in Overriding and Hiding\|http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.4.8.3]\]:

"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:

(The Java Language Specification, §8.4.8.3, "Requirements in Overriding and Hiding" [JLS 2015]). The following table lists the allowed accesses.

Overridden/Hidden Method Modifier	Overriding/Hiding Method Modifier

Overridden/hidden method modifier

Overriding/hiding method modifier


`public`	`public`
`protected`	`protected` or `public`
default	default or `protected` or

private

`public`
`private`	Cannot be overridden

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 demonstrates how a malicious subclass Sub can both override the doLogic() method of the superclass and increase the accessibility of the super classoverriding method. Any user of Sub will be able to can invoke the doLogic method since because 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 Super defines it to be protected, 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 Do restrictivesensitive 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.This compliant solution declares the doLogic() method final to prevent malicious overriding:

Code Block

bgColor	#ccccff


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

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 to be weakened, possibly compromising , which can compromise the security of a Java application.

Rule	Severity	Likelihood	Remediation Cost	Priority	Level

SCP01

MET04-J

medium

Medium

probable

Probable

medium

Medium

P8

L2

Automated Detection

TODO

Related Vulnerabilities

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

References

...

Detecting violations of this rule is straightforward.

Tool

Version

Checker

Description

Parasoft Jtest

Include Page

	Parasoft_V
	Parasoft_V

CERT.MET04.OPM

Do not override an instance "private" method

Related Guidelines

MITRE CWE	CWE-487, 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