OBJ33-J Limit extensibility of classes and methods

<!-- /* Font Definitions */ @font-face

@font-face

@font-face

/* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal

h2

span.Heading2Char

.MsoChpDefault

@page Section1

div.Section1

/* List Definitions */ @list l0

@list l0:level1

ol

ul

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

Non Compliant code example:

public class NonFinal {

 

    // sole constructor

    public NonFinal()

}

 

Here, an attacker can easily create an instance and override methods of the NonFinal class.

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)

        // continue

    }

 

    private void securityManagerCheck() {

        SecurityManager sm = System.getSecurityManager();

        if (sm != null)

    }

}

Risk Assessment:

Allowing a non-final class or method to be inherited without checking the class instances, allows an attacker to exploit it.

TODO

Related Vulnerabilities

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

Reference:

1. Secure Coding Guidelines for the Java Programming Language http://java.sun.com/security/seccodeguide.html
2. Li Gong, Gary Ellison, and Mary Dageforde.
   Inside Java 2 Platform Security. 2nd ed.
   Boston, MA: Addison-Wesley, 2003.
3. Joshua Bloch. Effective Java Programming Language Guide.
   1st ed. Addison-Wesley Professional, 2001.