Page History

Developers often separate program logic across multiple classes or files to modularize code and to increase re-usability. When developers modify a superclass (during maintenance, for example), the developer must ensure that changes in superclasses preserve all of the program invariants on which the subclasses depend. Failure to maintain all relevant invariants can cause security vulnerabilities.

...

This noncompliant code example relies on a class Account that stores banking-related information , with no inherent security. Security is delegated to the subclass BankAccount. The client application is required to use BankAccount because it contains the security mechanism.

...

At a later date, the maintainer of the class Account added a new method called overdraft(). However, the BankAccount class maintainer is unaware of the change. The client application subsequently became vulnerable to malicious invocations. For example, the overdraft() method could be invoked directly on a BankAccount object, avoiding the security checks that should have been present. The following noncompliant code example illustrates this vulnerability.

...

The {{Provider}} class inherits the {{put()}} and {{remove()}} methods from {{Hashtable}} and adds security manager checks to each. These checks ensure that malicious code cannot add or remove the mappings. When {{entrySet()}} was introduced, it became possible for untrusted code to remove the mappings from the {{Hashtable}} because {{Provider}} did not override this method to provide the necessary security manager check \[[SCG 2007|AA. Bibliography#SCG 07]\]. This problem is commonly know as a "fragile class hierarchy" in other object-oriented languages, such as C+\+.

Noncompliant Code Example (Calendar)

This noncompliant code example overrides the methods after() and compareTo() of the class java.util.Calendar. The Calendar.after() method returns a boolean value that indicates whether or not the Calendar represents a time after that represented by the specified Object parameter. The programmer wishes to extend this functionality so that the after() method returns true even when the two objects represent the same date. The programmer also overrides the method compareTo() to provide a "comparisons by day" option to clients . For (for example, comparing today's day date with the first day of week (, which differs from country to country) , to check whether it is a weekday).

class CalendarSubclass extends Calendar {
  @Override public boolean after(Object when) {
    // correctly calls Calendar.compareTo()
    if (when instanceof Calendar && super.compareTo((Calendar) when) == 0) {
      return true;
    }
    return super.after(when);
  }
	
  @Override public int compareTo(Calendar anotherCalendar) {
    return compareDays(this.getFirstDayOfWeek(), anotherCalendar.getFirstDayOfWeek());
  }

  private int compareDays(int currentFirstDayOfWeek, int anotherFirstDayOfWeek) {
    return (currentFirstDayOfWeek > anotherFirstDayOfWeek) ?
           1 : (currentFirstDayOfWeek == anotherFirstDayOfWeek) ? 0 : -1;
  }

  public static void main(String[] args) {
    CalendarSubclass cs1 = new CalendarSubclass(); 
    cs1.setTime(new Date());                       
    cs1.set( Calendar.DAY_OF_WEEK, Calendar.SUNDAY); // Date of last Sunday (before now)
    CalendarSubclass cs2 = new CalendarSubclass();   // Wed Dec 31 19:00:00 EST 1969
    System.out.println(cs1.after(cs2));              // expected to print true
  }

  // Implementation of other Calendar abstract methods 
}

...

The {{java.util.Calendar}} class provides a {{compareTo()}} method, and an {{after()}} method. The {{after()}} method is documented as follows:in (\[[API 2006|AA. Bibliography#API 06]\])as follows: 

The after() method returns Returns whether this Calendar represents a time after the time represented by the specified Object. This method is equivalent to:
compareTo(when) > 0
if and only if when is a Calendar instance. Otherwise, the method returns false.

...

In this case, the two objects are initially compared using the overriding CalendarSubclass.after() method. This invokes the superclass' s Calendar.after() method to perform the remainder of the comparison. But the Calendar.after() method internally calls the compareTo() method, which is delegated to CalendarSubclass.compareTo(). Consequently, CalendarSubclass.after() actually calls CalendarSubclass.compareTo(), and consequently returns false.

The developer of the subclass was unaware of the implementation details of Calendar.after() and incorrectly assumed that the superclass's after() method would invoke only its own methods without invoking overriding methods from the subclass. Guideline "MET04-J. Ensure that constructors do not call overridable methods" describes similar programming errors.

...

This compliant solution uses a design pattern called composition and forwarding (sometimes also referred to as delegation) \[[Lieberman 1986|AA. Bibliography#Lieberman 86]\] and \[[Gamma 1995|AA. Bibliography#Gamma 95, p. 20]\]. The compliant solution introduces a new _forwarder_ class that contains a {{private}} member field of the {{Calendar}} type; this is _composition_ rather than inheritance. In this example, the field refers to {{CalendarImplementation}}, a concrete instantiable implementation of the {{abstract}} {{Calendar}} class. The compliant solution also introduces a wrapper class called {{CompositeCalendar}} that provides the same overridden methods found in the {{CalendarSubclass}} from the preceding noncompliant code example.

...

Note that each method of the class ForwardingCalendar redirects to methods of the contained CalendarImplementation class, from which it receives return values; this is the forwarding mechanism. The ForwardingCalendar class is largely independent of the implementation of the class CalendarImplementation. Consequently, future changes to CalendarImplementation are unlikely to break ForwardingCalendar and thus are also unlikely to break CompositeCalendar. Invocations of CompositeCalendar's the overriding after() method of CompositeCalendar perform the necessary comparison by using the CalendarImplementation.compareTo() method as required. Using super.after(when) forwards to ForwardingCalendar which invokes the CalendarImplementation.after() method as required. ConsequentlyAs a result, ava.util.Calendar.after() invokes the CalendarImplementation.compareTo() method as required, with the result that resulting in the program correctly prints printing true.

Risk Assessment

Modifying a superclass without considering the effect on subclasses can introduce vulnerabilities. Subclasses that are unaware of the superclass implementation may can be subject to erratic behavior, resulting in inconsistent data state and mismanaged control flow.

...

Sound automated detection is not currently feasible.

...

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

Bibliography

\[[API 2006|AA. Bibliography#API 06]\] [Calendar|http://download.oracle.com/javase/6/docs/api/java/util/Calendar.html]
\[[Bloch 2008|AA. Bibliography#Bloch 08]\] Item 16: "Favor composition over inheritance"
\[[Gamma 1995|AA. Bibliography#Gamma 95]\] Design Patterns: Elements of Reusable Object-Oriented Software
\[[Lieberman 1986|AA. Bibliography#Lieberman 86]\] Using prototypical objects to implement shared behavior in object-oriented systems
\[[SCG 2007|AA. Bibliography#SCG 07]\] Guideline 1-3 Understand how a superclass can affect subclass behavior

...