A non-final class or method that is not meant to be inherited can be overridden by an attacker if it is not declared final. Sometimes, only trusted implementations should be allowed to extend the class. Because declaring the class final is overly prohibitive in such cases, it must be carefully designed for inheritance.
Consider two classes belonging to different protection domains. One of them is malicious whereas the other is trusted. If the malicious class extends the trusted {{public}} non-final class and inherits without overriding a method of the trusted class, the fully qualified invocation of the malicious class's version of the method uses the protection domain of the trusted class. In this case, the trusted class's permissions are examined to execute the method. \[[Gong 03|java:AA. Java References#Gong 03]\]) |
At all points that the class can be instantiated, there must be checks to ensure that the instance being created has the same type as the class. If the type is found to be that of a subclass, instead of the non-final public superclass', a security manager check must be performed to ensure that malicious classes cannot misuse the class.
The use of reflection is necessary if the non-final class has members that are declared private or are otherwise inaccessible to the attacker. Declaring the class or its methods final prohibits this level of access.
In this noncompliant code example, a malicious class can extend the public non-final class, NonFinal. As a result, it can call any of its instance methods and access its protected fields.
public class NonFinal {
public NonFinal() {
// ...
}
}
|
This compliant solution installs a security manager check in the constructor of the non-final class. Access is denied if the security manager detects that a subclass without the requisite permissions, is trying to instantiate the superclass. \[[SCG 07|java:AA. Java References#SCG 07]\] |
public class NonFinal {
public NonFinal() {
// Invoke java.lang.Object.getClass to get class instance
Class c = getClass();
// Confirm class type
if (c != NonFinal.class) {
// Check the permission needed to subclass NonFinal
securityManagerCheck(); // throws a security exception if not allowed
}
// ...
}
}
|
It is critical to compare the class types and not the class names (OBJ06-J. Compare classes and not class names).
Allowing a non-final class or method to be inherited without checking the class instance allows a malicious subclass to misuse the privileges of the class.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
|---|---|---|---|---|---|
OBJ33- J |
medium |
likely |
medium |
P12 |
L1 |
Search for vulnerabilities resulting from the violation of this rule on the CERT website
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
\[[McGraw 00|java:AA. Java References#McGraw 00]\] Chapter Seven Rule 3: "Make Everything Final, Unless There's a Good Reason Not To" \[[Lai 08|java:AA. Java References#Lai 08]\] \[[SCG 07|java:AA. Java References#SCG 07]\] Guideline 1-2 "Limit the extensibility of classes and methods" \[[Gong 03|java:AA. Java References#Gong 03]\] Chapter 6: "Enforcing Security Policy" \[[Bloch 08|java:AA. Java References#Bloch 08]\] Item 1: "Consider static factory methods instead of constructors" |
OBJ04-J. Do not allow partially initialized objects to be accessed 08. Object Orientation (OBJ) OBJ06-J. Compare classes and not class names