According to the Java Language Specification \[[JLS 2005|AA. Java References#JLS 05]\], 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 following are the allowed accesses:
Overridden/hidden method modifier |
Overriding/hiding method modifier |
|---|---|
|
|
|
|
default |
default or |
|
Cannot be overridden |
This means that there is potential for some functionality having a restrictive access modifier to be overridden by a less restrictive access modifier.
This noncompliant code example exemplifies how a malicious subclass Sub can override the doLogic() method of the superclass. Any user of Sub will be able to invoke the doLogic method as the base class BadScope defines it with the protected access modifier. The class Sub can allow more access than BadScope by declaring its own version of the doLogic() method {{public}.
class BadScope {
protected void doLogic() {
System.out.println("Super invoked");
}
}
public class Sub extends BadScope {
public void doLogic() {
System.out.println("Sub invoked");
// Do sensitive operations
}
}
|
Do not override a method unless absolutely necessary. Declare all methods and fields final to avoid malicious subclassing. When this is not possible, refrain from increasing the accessibility of overridden methods. This is in compliance with the tenets of 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
}
}
|
This noncompliant code example overrides the finalize() method of the superclass Base, and changes 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.finalizemethod and declares that methodpublic, 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.
final class SubClass extends Base {
public void finalize() {
// ...
}
}
|
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.
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.
SPC01-EX1: According to Sun's Secure Coding Guidelines [[SCG 2007]]
One noteworthy exception to this guideline pertains to classes that implement the
java.lang.Cloneableinterface. In these cases, the accessibility of theObject.clonemethod should be increased fromprotectedtopublic.
Subclassing allows access restrictions to be weakened, possibly compromising the security of a Java application.
Guideline |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
|---|---|---|---|---|---|
SCP01- J |
medium |
probable |
medium |
P8 |
L2 |
TODO
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
\[[JLS 2005|AA. Java References#JLS 05]\] [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] [\[[SCG 2007|AA. Java References#SCG 07]\]] Guideline 1-1 Limit the accessibility of classes, interfaces, methods, and fields \[[MITRE 2009|AA. Java References#MITRE 09]\] [CWE ID 487|http://cwe.mitre.org/data/definitions/487.html] "Reliance on Package-level Scope" |
SCP00-J. Use as minimal scope as possible for all variables 05. Scope (SCP) SCP02-J. Do not reuse names