Page History

...

Methods that receive arguments across a trust boundary , must perform callee validation of their arguments for safety and security reasons. This precaution applies to all public methods of a library. Other methods, including private methods, should validate arguments that are both untrusted and unvalidated when those arguments may propagate from a public method via its arguments.

When defensive copying is necessary, make the defensive copies before argument validation, and validate the copies rather than the original arguments . See rule (see SER06-J. Make defensive copies of private mutable components during deserialization for additional information).

Noncompliant Code Example

In this noncompliant code example, setState() and useState() fail to validate their arguments. A malicious caller could pass an invalid state to the library, consequently corrupting the library and exposing a vulnerability.

private Object myState = null;

// Sets some internal state in the library
void setState(Object state) {
  myState = state;
}

// Performs some action using the state passed earlier
void useState() {
  // Perform some action here
}

...

This compliant solution both validates the method arguments and verifies the internal state before use. This practice promotes consistency in program execution and reduces the potential for vulnerabilities.

private Object myState = null;

// Sets some internal state in the library
void setState(Object state) {
  if (state == null) {
    // Handle null state
  }

  // Defensive copy here when state is mutable

  if (isInvalidState(state)) {
    // Handle invalid state
  }
  myState = state;
}

// Performs some action using the state passed earlier
void useState() {
  if (myState == null) {
    // Handle no state (e.g., null) condition
  }
  // ...
}

...

MET00-EX1: Argument validation may be omitted for arguments whose type adequately constrains the state of the argument. This constraint should be clearly documented in the code.

This exception may include apply to arguments whose values (as permitted by their type) are not necessarily valid but are still correctly handled by the method. In the following code, the arguments x and y are not validated even though their product might not be a valid int. The code is safe because it adequately handles all int values for x and y.

public int product(int x, int y) {
  long result = (long) x * y;
  if (result < Integer.MIN_VALUE || result > Integer.MAX_VALUE) {
    // handleHandle error
  }
  return (int) result;
}

MET00-EX2: Complete validation of all arguments of all methods may introduce added cost and complexity that exceeds its value for all but the most critical code. In such cases, consider argument validation at API boundaries, especially those that may involve interaction with untrusted code.

Risk Assessment

Failure to validate method arguments can result in inconsistent computations, runtime exceptions, and control flow vulnerabilities.

Related Guidelines

Bibliography

...

Rule 06: Methods (MET)      Rule 06: Methods (MET)