Some classes ("parent classes" hereafter) must permit extension by trusted subclasses while simultaneously preventing extension by untrusted code. Declaring such parent classes to be final
is overly prohibitivenot an option, because it would prevent all extension and overriding. This case requires by trusted code. Such problems require careful design for inheritance.
Wiki Markup |
---|
Consider two classes belonging to different protection domains; one is malicious, and estends the other, which is a trusted parent class. When theConsider maliciousan classobject extendsof the trusted {{public}} non-final parent class without overriding some method of the trusted class,malicious class with a fully qualified invocation of thea maliciousmethod class's version ofdefined by the methodtrusted usesparent, theand protectionnot domainoverridden ofby the trusted parentmalicious class. In this Consequentlycase, the trusted parent class's permissions are examined to execute the method, with the consequence that the malicious object gets the method invoked inside the protection domain of the trusted parent class. \[[Gong 2003|AA. Bibliography#Gong 03]\]. |
One commonly suggested (but ineffective) solution is to place code at each points point where the parent class can be instantiated to ensure that the instance being created has the same type as the parent class. When the type is found to be that of a subclass instead of the parent class's type, the checking code performs a security manager check to ensure that malicious classes cannot misuse the parent class. This approach is insecure because it allows a malicious class to add a finalizer and obtain a partially initialized instance of the parent class (see . This attack is detailed in guideline OBJ04-J. Do not allow access to partially initialized objects).
For non-final classes, the method that performs the security manager check must be invoked as an argument to a private
constructor to ensure that the security check is performed before any superclass's constructor can exit.
...
In this noncompliant code example, a malicious class can extend the public
non-final parent class, NonFinal
. Consequently, the attacker can invoke any of the parent class's accessible instance methods and , can access the parent class's protected
fields, and can even override any of the parent class's accessible non-final methods.
Code Block | ||
---|---|---|
| ||
public class NonFinal { public NonFinal() { // ... } } |
Noncompliant Code Example (Security Manager)
Wiki Markup |
---|
This noncompliant code example installs a security manager check in the constructor of the non-final parent class. The security manager denies access when it detects that a subclass without the requisite permissions is attempting to instantiate the superclass \[[SCG 2007|AA. Bibliography#SCG 07]\]. It also compares class types, in compliance with [OBJ06-J. Compare classes and not class names]. |
Code Block | ||
---|---|---|
| ||
public class NonFinal { public NonFinal() { Class c = getClass(); // Invoke java.lang.Object.getClass(), towhich get class instance Class c = getClass();is final // Confirm class type if (c != NonFinal.class) { // Check the permission needed to subclass NonFinal securityManagerCheck(); // throws a security exception if not allowed } // ... } } |
HoweverUnfortunately, throwing an exception from the constructor of a non-final class is insecure because it allows a finalizer attack (see guideline OBJ04-J. Do not allow access to partially initialized objects).
This noncompliant code example does, however, comply with guideline OBJ06-J. Compare classes and not class names because it compares class types and not class names.
...
Compliant Solution (Java SE 6+, public and private constructors)
This compliant solution invokes a security manager check as a side-effect of computing the boolean value passed to a private constructor (as seen in guideline OBJ04-J. Do not allow access to partially initialized objects). The rules for order of evaluation require that the security manager check must execute before invocation of the private constructor. Consequently, the security manager check also executes before invocation of any superclass's constructor. Note that the security manager check is made without regard to whether the object under construction has the type of the parent class or the type of a subclass (whether trusted or not).
This solution thwarts the finalizer attack. It is specific to Java SE 6 and onwards, where a finalizer is prevented from being executed when an exception is thrown before the java.lang.Object
constructor exits SCG 2009.
Code Block | ||
---|---|---|
| ||
public class NonFinal { public NonFinal() { this(securityManagerCheck( check( this.getClass())); // throws a security exception if not allowed // ... } private NonFinal(boolean securityManagerCheck) { // Noregular statementsconstruction required goes here } private static boolean securityManagerCheckcheck(Class c) { // Perform security check Confirm class type if (c != NonFinal.class) { // Check the permission needed to subclass NonFinal securityManagerCheck(); // throws a security exception if not allowed } return true; } } |
Risk Assessment
Allowing Permitting 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.
...