Page History

Interfaces are used to group together all the methods that a class promises to publicly expose. The implementing classes are obliged to provide concrete implementations for all of these methods. Interfaces are a necessary ingredient of the most public API and APIs; once released, it flaws can be very hard to fix any flaws without breaking any code that implements the older version. The security specific repercussions include the following:

• The interface Interface changes resulting from security fixes can severely impair the contracts of the implementing classes. It is even possible that a security For example, a fix introduced in a later version is may be accompanied by modifications to an unrelated interface that must now be implemented by the client. This can prevent the client The client may be prevented from implementing the security fix because the new interface may impose additional implementation burden on it.
• If an insider crafts changes to an interface or someone accidentally makes modifications, most of the client code that implements the interface will break resulting in denial of service. This is particularly pernicious in distributed Java based applications.
• Implementers can provide default or skeletal implementations that the clients can directly extend, of interface methods for their clients to extend; however, such code can adversely affect the behavior of the subclasses. When Conversely, when such default implementations are not providedabsent, the subclasses are forced to must provide dummy implementations. This fosters Such implementations  foster an environment where comments such as '"ignore this code, does nothing', " occur incessantly. Such code may never even get tested.
• If there is a security flaw in a public API (consider ThreadGroups, CON17see, for example, the discussion of ThreadGroup methods in THI01-J. Avoid using ThreadGroup APIs) Do not invoke ThreadGroup methods), it will persist throughout the lifetime of the API, affecting the security of any application or library that uses it. Even after the security flaw is mitigated, applications and libraries may continue using the insecure version until they are also updated.

Noncompliant Code Example

In this noncompliant code example, an interface User is frozen with two methods: authenticate() and subscribe(). Sometime Some time later, the providers release a free service that does not rely on authentication. The addition of the freeService() method, unfortunately, breaks all the client code that implements the interface. Moreover, the implementers who wish to use only freeService have to face the onus of also providing the other two methods which pollute the API, for reasons discussed earlier.

public interface User {
  boolean authenticate(String username, char[] password);
  void subscribe(int noOfDays);
  void freeService(); // introducedIntroduced after the class is publicly released
}

The addition of the freeService() method, unfortunately, breaks all the client code that implements the interface. Moreover, the implementers who wish to use only freeService() have to face the onus of also providing the other two methods, which pollute the API, for reasons discussed earlier.

Noncompliant Code Example

An alternative idea is to prefer abstract classes for dealing with constant evolution, but this that comes at the cost of flexibility that interfaces offer (a class may implement multiple interfaces but extend only one class). One notable pattern is for the provider to distribute an abstract skeletal class that implements the evolving interface. The skeletal class can selectively implement a few methods and force the extending classes to provide concrete implementations of the others. If a new method is added to the interface, the skeletal class can provide a non-abstract nonabstract default implementation that the extending class can optionally override. This pattern is dangerous because a provider is unaware of the extending class's code and may choose an implementation that introduces security weaknesses in the client APInoncompliant code example shows such a skeletal class.

public interface User {
  boolean authenticate(String username, char[] password);
  void subscribe(int noOfDays);
  void freeService(); // Introduced after the API is publicly released
}

abstract class SkeletalUser implements User {
  public abstract boolean authenticate(String username, char[] password);
  public abstract void subscribe(int noOfDays);
  public void freeService() { 
    // Added later, provide implementation and re-release class 
  }
}

class Client extends SkeletalUser {
  // Implements authenticate() and subscribe(), not freeService()
}

Although useful, this pattern may be insecure because a provider who is unaware of the extending class's code may choose an implementation that introduces security weaknesses in the client API.

Compliant Solution (

...

Modularize)

A better design strategy is to anticipate the future evolution of the service. The core functionality should be implemented in the User interface and ; in this case, only the premium service may be required to extend from it. To avail make use of the new free service, an existing class may then choose to simply implement the new interface FreeUser, or it may just completely ignore it.

public interface User {
  boolean authenticate(String username, char[] password);
}

public interface PremiumUser extends User {
  void subscribe(int noOfDays);
}

public interface FreeUser {
  void freeService();
}

Compliant Solution (

...

Make New Method Unusable)

Another compliant solution is to throw an exception from within the new , freeService() method defined in the implementing subclass.

class Client implements User {
  public void freeService() {
    throw new AbstractMethodError();
  } 
}

Compliant Solution (

...

Delegate Implementation to Subclasses)

Although allowable, a less flexible compliant solution is to delegate the implementation of the method to subclasses of the client's core interface-implementing class.

abstract class Client implements User  {
  public abstract void freeService(); 
  // Delegate implementation of new method to subclasses
  // Other concrete implementations
}

A variant of compliant solution (2) can also be applied here by throwing an exception from the freeService() method after making the class (and method) non-abstract.

...

Compliant Solution (Java 8 Default Method)

Java versions 8 and newer allow an interface to provide a default method, which allows for extending interfaces without forcing the modification of preexisting classes which implement the interface.  Classes that implement this interface can ignore freeService() in which case the default implementation is used, or they can reimplement freeService() themselves, or they can declare it to be abstract, re-establishing the requirement for subclasses to to provide an implementation.

public interface User {
  boolean authenticate(String username, char[] password);
  void subscribe(int noOfDays);
  default void freeService() {   // Introduced after the class is publicly released
    // ...
  }
}

Applicability

Failing to publish stable, flaw-free interfaces can break the contracts of the implementing classes, pollute the client API, and possibly introduce security weaknesses in the implementing classes.

Related Vulnerabilities

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

References

\[[Bloch 08|AA. Java References#Bloch 08]\] Item 18: "Prefer interfaces to abstract classes"

Bibliography

...

Image Added Image Added Image AddedMSC08-J. Avoid cyclic dependencies between packages      49. Miscellaneous (MSC)      MSC10-J. Limit the lifetime of sensitive data