A non-final class or method, which is not meant to be inherited, can be overridden by an attacker, if it is not declared as final \[3\].
\\
In case inheritance is to be limited to trusted implementations for a public, non-final class, then the class type should be confirmed before creating the instance at each place where an instance of the non-final class can be created. A SecurityManager check should be enforced on detecting a subclass (Chapter 6 of \[2\]).
A non-final class can be subverted simply by declaring a malicious class that inherits from the non-final class which implies that there is no need for reflection. However, reflection is necessary if the non-final class is private or otherwise inaccessible to the attacker.
h2. Non Compliant code example:
public class NonFinal {
// sole constructor
public NonFinal(){ // invoke java.lang.Object.getClass to get class instance
Class clazz = getClass();
// continue
} continue
}
\\ \\
}
Here, an attacker can easily create an instance and override methods of the NonFinal class.
h2. Compliant Solution:
The compliant solution confirms the object's class type by examining the java.lang.Class instance belonging to that object since the instances are scoped by the class name and the class loader that defined the class.
public class NonFinal {
// sole constructor
public NonFinal() {
{ Â Â Â Â Â Â Â // invoke java.lang.Object.getClass to get class instance
       Class clazz = getClass();
       // confirm class type
       if (clazz \!= NonFinal.class)
{                     // permission needed to subclass NonFinal                     securityManagerCheck();         }\\
\\
\\
\\
// continue
}
private void securityManagerCheck() {
SecurityManager
{ Â Â Â Â Â Â Â SecurityManager sm = System.getSecurityManager();
       if (sm \!= null)
{ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â sm.checkPermission(...); Â Â Â Â Â Â Â }\\
\\
\\
\\
}
}
h2. Risk Assessment:
Allowing a non-final class or method to be inherited without checking the class instances, allows an attacker to exploit it.
|| Rule \\ || Severity \\ || Likelihood \\ || Remediation Cost \\ || Priority \\ || Level \\ ||
| OBJ33-J | high | probable \\ | high \\ | P3 \\ | L3 \\ |
h2. Automated Detection
TODO
h2. Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website
h2. Reference:
# Secure Coding Guidelines for the Java Programming Language [http://java.sun.com/security/seccodeguide.html]
# Li Gong, Gary Ellison, and Mary Dageforde.
Inside Java 2 Platform Security. 2nd ed.
Boston, MA: Addison-Wesley, 2003.
# Joshua Bloch. Effective Java Programming Language Guide.
1st ed. Addison-Wesley Professional, 2001. | 