View Source

It is common for developers to separate the program logic into different classes or files to encourage modularity and re-usability. Unfortunately, this often imposes maintenance hurdles such as ensuring that the superclass does not change and in turn indirectly affect subclass behavior in undesired ways.

For instance, the introduction of the {{entrySet}} method in the superclass {{java.util.Hashtable}} in JDK 1.2, left the {{java.security.Provider}} class vulnerable to malicious deletion of entries due to absence of security manager checks. (See \[[Guideline 1-3 Understand how a superclass can affect subclass behavior|http://java.sun.com/security/seccodeguide.html]\])

Noncompliant Code Example

This noncompliant example shows a class SuperClass that stores banking related information but delegates the security manager and input validation tasks to the class SubClass. The client application has to use SubClass since it contains authentication mechanisms as well. A new method called overdraft is added by the maintainer of class SuperClass and the extending class SubClass is not aware of this change. This exposes the client application to malicious invocations such as ones using the overdraft method on the currently in-use object. All security checks are deemed useless in such cases.

class SuperClass {  //Main Bank class maintains all data  during program execution
  private double balance=0;
 
  protected boolean withdraw(double amount) {
	 balance -= amount;
	 return true;	 
  }
 
  protected void overdraft() {  //this method was added at a later date
	balance += 300; //add 300 in case there is an overdraft
	System.out.println("The balance is :" + balance);
  }
}

class SubClass extends SuperClass {	//all users have to subclass this to proceed
  public boolean withdraw(double amount) {
    // inputValidation();
    // securityManagerCheck();
    // Login by checking credentials using database and then call a method in SuperClass 
    // that updates the balance field to reflect current balance, other details
    return true;
  }			
 
  public void doLogic(SuperClass sc,double amount) {
    sc.withdraw(amount);
  }
}

public class Affect {
  public static void main(String[] args) {
    SuperClass sc = new SubClass();  //override
    SubClass sub = new SubClass();  //need instance of SubClass to call methods

    if(sc.withdraw(200.0)) { //validate and enforce security manager check 
      sc = new SuperClass(); //if allowed perform the withdrawal
      sub.doLogic(sc, 200.0); //pass the instance of SuperClass to use it
    }
    else
      System.out.println("You do not have permission/input validation failed!");	
      sc.overdraft(); //newly added method, has no security manager checks. Beware!
    }
}

Compliant Solution

Always keep the following postulates in mind:

Understand what the superclass does and watch out for mutating functionality
Make sure that new methods that are added to the superclass are overridden appropriately if there is some division of logic
Never modularize in absurd ways as is apparent in the noncompliant code example

Risk Assessment

Modifying a superclass without considering the effect on a subclass can introduce vulnerabilities.

Rule	Severity	Likelihood	Remediation Cost	Priority	Level
OBJ01-J	medium	probable	high	P4	L3

Automated Detection

TODO

Related Vulnerabilities

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

References

\[[SCG 07|AA. Java References#SCG 07]\] Guideline 1-3 Understand how a superclass can affect subclass behavior

OBJ00-J. Declare data members private 06. Objects Orientation (OBJ) OBJ02-J. Avoid using finalizers