...
| Code Block | ||
|---|---|---|
| ||
private class Account {
// Maintains all banking -related data such as account balance
private double balance = 100;
boolean withdraw(double amount) {
if ((balance - amount) >= 0) {
balance -= amount;
System.out.println("Withdrawal successful. The balance is : "
+ balance);
return true;
}
return false;
}
}
public class BankAccount extends Account {
// Subclass handles authentication
@Override boolean withdraw(double amount) {
if (!securityCheck()) {
throw new IllegalAccessException();
}
return super.withdraw(amount);
}
private final boolean securityCheck() {
// checkCheck that account management may proceed
}
}
public class Client {
public static void main(String[] args) {
Account account = new BankAccount();
// Enforce security manager check
boolean result = account.withdraw(200.0);
System.out.println("Withdrawal successful? " + result);
}
}
|
At a later date, the maintainer of the Account class added a new method called overdraft(). However, the BankAccount class maintainer was unaware of the change. Consequently, the client application 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 shows this vulnerability.:
| Code Block | ||
|---|---|---|
| ||
private class Account {
// Maintains all banking -related data such as account balance
private double balance = 100;
boolean overdraft() {
balance += 300; // Add 300 in case there is an overdraft
System.out.println("Added back-up amount. The balance is :"
+ balance);
return true;
}
// otherOther Account methods
}
public class BankAccount extends Account {
// Subclass handles authentication
// NOTE: unchanged from previous version
// NOTE: lacks override of overdraft method
}
public class Client {
public static void main(String[] args) {
Account account = new BankAccount();
// Enforce security manager check
boolean result = account.withdraw(200.0);
if (!result) {
result = account.overdraft();
}
System.out.println("Withdrawal successful? " + result);
}
}
|
While Although this code works as expected, it adds a dangerous attack vector. Because there is no security check on the overdraft() method has no security check, a malicious client can invoke it without authentication:
...
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 example, comparing today's date with the first day of the week, which differs from country to countryamong countries, to check whether it is a weekday).
| Code Block | ||
|---|---|---|
| ||
class CalendarSubclass extends Calendar {
@Override public boolean after(Object when) {
// correctlyCorrectly 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());
// Date of last Sunday (before now)
cs1.set(Calendar.DAY_OF_WEEK, Calendar.SUNDAY);
// Wed Dec 31 19:00:00 EST 1969
CalendarSubclass cs2 = new CalendarSubclass();
// expectedExpected to print true
System.out.println(cs1.after(cs2));
}
// Implementation of other Calendar abstract methods
}
|
...
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 the superclass's methods without invoking overriding methods from the subclass. Rule MET05-J. Ensure that constructors do not call overridable methods describes similar programming errors.
...
This compliant solution uses a design pattern called composition Composition and forwarding Forwarding (sometimes also called delegationDelegation) [Lieberman 1986], [Gamma 1995, 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.
| Code Block | ||
|---|---|---|
| ||
// The CalendarImplementation object is a concrete implementation
// of the abstract Calendar class
// Class ForwardingCalendar
public class ForwardingCalendar {
private final CalendarImplementation c;
public ForwardingCalendar(CalendarImplementation c) {
this.c = c;
}
CalendarImplementation getCalendarImplementation() {
return c;
}
public boolean after(Object when) {
return c.after(when);
}
public int compareTo(Calendar anotherCalendar) {
// CalendarImplementation.compareTo() will be called
return c.compareTo(anotherCalendar);
}
}
class CompositeCalendar extends ForwardingCalendar {
public CompositeCalendar(CalendarImplementation ci) {
super(ci);
}
@Override public boolean after(Object when) {
// This will call the overridden version, i.e.
// CompositeClass.compareTo();
if (when instanceof Calendar &&
super.compareTo((Calendar)when) == 0) {
// Return true if it is the first day of week
return true;
}
// DoesNo notlonger comparecompares with first day of week any longer;
// Usesuses default comparison with epoch
return super.after(when);
}
@Override public int compareTo(Calendar anotherCalendar) {
return compareDays(
super.getCalendarImplementation().getFirstDayOfWeek(),
anotherCalendar.getFirstDayOfWeek());
}
private int compareDays(int currentFirstDayOfWeek,
int anotherFirstDayOfWeek) {
return (currentFirstDayOfWeek > anotherFirstDayOfWeek) ? 1
: (currentFirstDayOfWeek == anotherFirstDayOfWeek) ? 0 : -1;
}
public static void main(String[] args) {
CalendarImplementation ci1 = new CalendarImplementation();
ci1.setTime(new Date());
// Date of last Sunday (before now)
ci1.set(Calendar.DAY_OF_WEEK, Calendar.SUNDAY);
CalendarImplementation ci2 = new CalendarImplementation();
CompositeCalendar c = new CompositeCalendar(ci1);
// expectedExpected to print true
System.out.println(c.after(ci2));
}
}
|
...
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
OBJ02-J | mediumMedium | probableProbable | highHigh | P4 | L3 |
Automated Detection
Sound automated detection is not currently feasible.
...
The introduction of the entrySet() method in the java.util.Hashtable superclass in JDK 1.2 left the java.security.Provider subclass vulnerable to a security attack. The Provider class extends java.util.Properties, which in turn extends Hashtable. The Provider class maps a cryptographic algorithm name (for example ", RSA") to a class that provides its implementation.
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 failed to override this method to provide the necessary security manager check [SCG 2009]. This situation is commonly known as the fragile class hierarchy problem.
...
[API 2006] | |
Item 16. , "Favor composition Composition over inheritanceInheritance" | |
Design Patterns, : Elements of Reusable Object-Oriented Software | |
"Using prototypical objects to implement shared behavior in object-oriented systemsPrototypical Objects to Implement Shared Behavior in Object-Oriented Systems" |
...