Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Edited by sciSpider Java v3.0 (sch jp)

...

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 non-compliant 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.

Code Block
bgColor#FFcccc
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>

Code Block
bgColor#ccccff
class BadScope {
  private final void doLogic() {System.out.println("Super invoked");}
}

Risk Assessment

TODO

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

SCP01-J

??

??

??

P??

L??

Automated Detection

TODO

Related Vulnerabilities

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

References

JLS 8.4.8.3 Requirements in Overriding and Hiding