MSC65-J. Incorporate diagnostic tests using assertions

Incorporate diagnostic tests into programs using the assert() statement.

Assertions are primarily intended for use during debugging and are generally turned off before code is deployed by using the -disableassertions (or -da) java option. Consequently, assertions should be used to protect against incorrect programmer assumptions and not for runtime error checking.

Assertions should never be used to verify the absence of runtime (as opposed to logic) errors, such as

• invalid user input (including command-line arguments and environment variables)
• file errors (for example, errors opening, reading, or writing files)
• network errors (including network protocol errors)

• out-of-memory conditions (when the Java Virtual Machine [JVM] cannot allocate space for a new object and the garbage collector cannot make sufficient space available)

• system resource exhaustion (for example, out-of-file descriptors, processes, threads)
• system call errors (for example, errors executing files, locking or unlocking mutexes)
• invalid permissions (for example, file, memory, user)

Code that protects against an input/output error, for example, cannot be implemented as an assertion because it must be presented in the deployed executable.

In particular, assertions are generally unsuitable for server programs or embedded systems in deployment. A failed assertion can lead to a denial-of-service (DoS) attack if triggered by a malicious user. In such situations, a soft failure mode, such as writing to a log file and rejecting the request, is more appropriate.

Noncompliant Code Example

This noncompliant code example uses the assert() statement to verify that input was available. Because input availability depends on the user and can become exhausted at any point during a process lifetime, a robust program must be prepared to gracefully handle and recover from its exhaustion. Therefore, using the assert() statement to verify that input was available would be inappropriate because doing so might lead to an abrupt termination of the process, opening up the possibility of a DoS attack.

BufferedReader br;

// Set up the BufferedReader br

String line;

// ...

line = br.readLine();

assert line != null;

Compliant Solution

This compliant solution demonstrates how to detect and handle possible input unavailability.

BufferedReader br;

// Set up the BufferedReader br

String line;

// ...

line = br.readLine();

if (line == null) {
  // handle error
}

Risk Assessment

Assertions are a valuable diagnostic tool for finding and eliminating software defects that may result in vulnerabilities. The absence of assertions, however, does not mean that code is incorrect.

Automated Detection

In general, the misuse of the assert statement for runtime checking rather than checking for logical errors cannot be detected automatically.

Related Vulnerabilities

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

Related Guidelines

This guideline is based on MSC11-C. Incorporate diagnostic tests using assertions and MSC11-CPP. Incorporate diagnostic tests using assertions.

Bibliography