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 most public 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:
- Interface changes resulting from security fixes can severely impair the contracts of the implementing classes. For example, a security fix introduced in a later version 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 problem is particularly pernicious in distributed Java-based applications.
- Implementers can provide default or skeletal implementations of interface methods for their clients to extend; however, such code can adversely affect the behavior of the subclasses. Conversely, when such default implementations are absent, the subclasses 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 , (e.g., ThreadGroups, see, for example, the discussion of
ThreadGroupmethods in THI01-J. Do not invoke ThreadGroup methods), it will persist throughout the lifetime of the application.
...
| Code Block | ||
|---|---|---|
| ||
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.
...
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.
Bibliography
| [Bloch 2008] | Item 18 |
...
| , "Prefer |
...
| Interfaces to |
...
| Abstract Classes" |
...