Page History

Redundant testing by caller and by callee as a style of defensive programming is largely discredited within discredited in the C and C++ communitycommunities, the main problem being performance. The usual discipline in C and C++ is to require validation on only on one side of each interface.

Requiring the caller to validate arguments can result in faster code , because the caller may understand certain invariants in that prevent invalid values from being passed. Requiring the callee to validate arguments allows the validation code to be encapsulated in one location, reducing the size of the code and making it more likely that these checks are performed in a consistent and correct fashion.

For safety and security reasons, this standard recommends that the called function validate its parameters. Validity checks allow the function to survive at least some forms of improper usage, enabling an application using the function to likewise survive, and often simplifies . Validity checks can also simplify the task of determining the condition that caused the invalid parameter.

...

In this noncompliant code example, setfile() and usefile() do not validate their parameters. It is possible that an invalid file pointer may can be used by the library, corrupting the library's internal state and exposing a vulnerability.

/* setsSets some internal state in the library */
extern int setfile(FILE *file);

/* performsPerforms some action using the file passed earlier */
extern int usefile();

static FILE *myFile;

void setfile(const FILE *file) {
    myFile = file;
}

void usefile(void) {
    /* performPerform some action here */
}

The vulnerability may can be more severe if the internal state references sensitive or system-critical data.

...

Validating the function parameters and verifying the internal state leads to consistency of program execution and may eliminate potential vulnerabilities. In addition, implementing commit /or rollback semantics (leaving program state unchanged on error) is a desirable practice for error safety.

/* setsSets some internal state in the library */
extern interrno_t setfile(FILE *file);

/* performsPerforms some action using the file passed earlier */
extern interrno_t usefile(void);

static FILE *myFile;

errno_t setfile(FILE *file) {
 if (file && !ferror(file) && !feof(file)) {
    myFile = file;
    return 0;
  }

  /* errorError safety: leave myFile unchanedunchanged */
  return EINVAL-1;
}

errno_t usefile(void) {
  if (!myFile) return -1;

    /*
     * performPerform other checks if needed,; return 
     * error condition.
     */

    /* performPerform some action here */
    return 0;
}

...

Failing to validate the parameters in library functions may result in an access violation or a data integrity violation. Such a scenario is indicative of scenario indicates a flaw in how the manner in which the library is used by the calling code. However, it the library itself may still be the library itself that is the vector by which the calling code's vulnerability is exploited.

Automated Detection

...

Tool	Version	Checker	Description
Astrée	Include Page Astrée_V Astrée_V		Supported
CodeSonar	Include Page CodeSonar_V CodeSonar_V	LANG.STRUCT.UPD	Unchecked parameter dereference
Parasoft C/C++test	Include Page Parasoft_V Parasoft_V	CERT_C-API00-a	The validity of parameters must be checked inside each function
PC-lint Plus	Include Page PC-lint Plus_V PC-lint Plus_V	413, 613, 668	Partially supported: reports use of null pointers including function parameters which are assumed to have the potential to be null
PVS-Studio	Include Page PVS-Studio_V PVS-Studio_V	V781, V1111

Related Vulnerabilities

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

Other Languages

...

Related Guidelines

Key here (explains table format and definitions)

...

...

Bibliography

...

Image Added Image Added Image Added

References

\[[Apple 06|AA. C References#Apple 06]\] [Application Interfaces That Enhance Security|http://developer.apple.com/documentation/Security/Conceptual/SecureCodingGuide/Articles/AppInterfaces.html], May 2006.
\[[MITRE 07|AA. C References#MITRE 07]\] [CWE ID 20|http://cwe.mitre.org/data/definitions/20.html], "Insufficient Input Validation"

Image Removed      49. Miscellaneous (MSC)      MSC09-C. Character Encoding - Use Subset of ASCII for Safety