Kingdom: API Abuse

An API is a contract between a caller and a callee. The most common forms of API abuse are caused by the caller failing to honor its end of this contract. For example, if a program fails to call chdir() after calling chroot(), it violates the contract that specifies how to change the active root directory in a secure fashion. Another good example of library abuse is expecting the callee to return trustworthy DNS information to the caller. In this case, the caller abuses the callee API by making certain assumptions about its behavior (that the return value can be used for authentication purposes). One can also violate the caller-callee contract from the other side. For example, if a coder subclasses SecureRandom and returns a non-random value, the contract is violated.

Missing Check against Null

Abstract

The program might dereference a null-pointer because it does not check the return value of a function that might return null.

Explanation

Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this function call can never fail" and "it doesn't matter if this function call fails". When a programmer ignores the return value from a function, they implicitly state that they are operating under one of these assumptions.
Example 1: The following code does not check to see if the string returned by the Item property is null before calling the member function Equals(), potentially causing a null dereference.


string itemName = request.Item(ITEM_NAME);
	if (itemName.Equals(IMPORTANT_ITEM)) {
		...
	}
	...

The traditional defense of this coding error is:

"I know the requested value will always exist because.... If it does not exist, the program cannot perform the desired behavior so it doesn't matter whether I handle the error or simply allow the program to die dereferencing a null value."

But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved.

References

[1] Standards Mapping - Common Weakness Enumeration CWE ID 253, CWE ID 690

[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [14] CWE ID 476

[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [13] CWE ID 476

[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [15] CWE ID 476

[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [11] CWE ID 476

[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [12] CWE ID 476

[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094

[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data

[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)

[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection

[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 11.1.7 Business Logic Security Requirements (L2 L3)

[12] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service

[13] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9

[14] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3120 CAT II, APP6080 CAT II

[15] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3120 CAT II, APP6080 CAT II

[16] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3120 CAT II, APP6080 CAT II

[17] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3120 CAT II, APP6080 CAT II

[18] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3120 CAT II, APP6080 CAT II

[19] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3120 CAT II, APP6080 CAT II

[20] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3120 CAT II, APP6080 CAT II

[21] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II

[22] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II

[23] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II

[24] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II

[25] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II

[26] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II

[27] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II

[28] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II

[29] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II

[30] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II

[31] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II

[32] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II

[33] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II

[34] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II

[35] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002400 CAT II

[36] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)

[37] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service

desc.controlflow.dotnet.missing_check_against_null

Abstract

The program can dereference a null-pointer because it does not check the return value of a function that might return null.

Explanation

Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this function call can never fail" and "it doesn't matter if this function call fails". When a programmer ignores the return value from a function, they implicitly state that they are operating under one of these assumptions.
Example 1: The following code does not check to see if memory allocation succeeded before attempting to use the pointer returned by malloc().


    buf = (char*) malloc(req_size);
    strncpy(buf, xfer, req_size);

The traditional defense of this coding error is:

"If my program runs out of memory, it will fail. It doesn't matter whether I handle the error or simply allow the program to die with a segmentation fault when it tries to dereference the null-pointer."

This argument ignores three important considerations:

- Depending upon the type and size of the application, it may be possible to free memory that is being used elsewhere so that execution can continue.

- It is impossible for the program to perform a graceful exit if required. If the program performs an atomic operation, it can leave the system in an inconsistent state.

- The programmer has lost the opportunity to record diagnostic information. Did the call to malloc() fail because req_size was too large or because there were too many requests being handled at the same time? Or was it caused by a memory leak that has built up over time? Without handling the error, there is no way to know.

References

[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley

[2] Standards Mapping - Common Weakness Enumeration CWE ID 253, CWE ID 690

[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [14] CWE ID 476

[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [13] CWE ID 476

[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [15] CWE ID 476

[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [11] CWE ID 476

[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [12] CWE ID 476

[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094

[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data

[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)

[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection

[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 11.1.7 Business Logic Security Requirements (L2 L3)

[13] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service

[14] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9

[15] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3120 CAT II, APP6080 CAT II

[16] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3120 CAT II, APP6080 CAT II

[17] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3120 CAT II, APP6080 CAT II

[18] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3120 CAT II, APP6080 CAT II

[19] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3120 CAT II, APP6080 CAT II

[20] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3120 CAT II, APP6080 CAT II

[21] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3120 CAT II, APP6080 CAT II

[22] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II

[23] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II

[24] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II

[25] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II

[26] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II

[27] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II

[28] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II

[29] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II

[30] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II

[31] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II

[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II

[33] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II

[34] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II

[35] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II

[36] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002400 CAT II

[37] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)

[38] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service

desc.controlflow.cpp.missing_check_against_null

Abstract

The program can dereference a null-pointer because it does not check the return value of a function that might return null.

Explanation

Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this function call can never fail" and "it doesn't matter if this function call fails". When a programmer ignores the return value from a function, they implicitly state that they are operating under one of these assumptions.

Example 1: The following code does not check to see if the string returned by getParameter() is null before calling the member function compareTo(), potentially causing a null dereference.


String itemName = request.getParameter(ITEM_NAME);
	if (itemName.compareTo(IMPORTANT_ITEM)) {
		...
	}
	...

Example 2:. The following code shows a system property that is set to null and later dereferenced by a programmer who mistakenly assumes it will always be defined.


System.clearProperty("os.name");
...
String os = System.getProperty("os.name");
if (os.equalsIgnoreCase("Windows 95") )
	System.out.println("Not supported");