SCP01-J. When developing Java clients (applets, mobile) assume that all scope can be overridden or modified

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 even though the base class BadScope defined it with the private access modifier.

class BadScope {
  private 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 <xyz rule>

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

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

SCP00-J. Use as minimal scope as possible for all variables and methods      03. Scope (SCP)      SCP02-J. Use nested classes carefully