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.

93 items found
Weaknesses
Abstract
Functions that cannot be used safely should never be used.
Explanation
Certain functions behave in dangerous ways regardless of how they are used. Functions in this category were often implemented without taking security concerns into account.

desc.semantic.cpp.dangerous_function.master
Abstract
Functions that cannot be used safely should never be used.
Explanation
Certain functions behave in dangerous ways regardless of how they are used. Functions in this category were often implemented without taking security concerns into account.

desc.semantic.php.dangerous_function.master
Abstract
Functions that cannot be used safely should never be used.
Explanation
DBMS_UTILITY.EXEC_DDL_STATEMENT will only execute statements classified as part of the Data Definition Language. Other statements not supported by embedded SQL will be silently ignored. This behavior makes it difficult to detect errors when using the procedure.
References
[1] How to write SQL injection proof PL/SQL
desc.semantic.sql.dangerous_function_exec_ddl
Abstract
Functions that cannot be used safely or are very difficult to do so should not be used.
Explanation
Certain functions behave in dangerous or unexpected ways. Functions in this category were often implemented without taking security concerns into account.

desc.structural.ruby.dangerous_function
Abstract
Using undocumented function an attacker could inject malicious functionality into the application.
Explanation
Use of ASNative function was detected. ASNative is an undocumented function reference list. Developers can use the list to call Flash system functions by using indices into the list. For example, the trace() function can also be referenced as ASNative(100, 4). Since the use of ASNative allows a developer to hide the intended function name, this could indicate a malicious intent. Support for ASNative has been discontinued for Flash Player versions 7 and above. ASNative function can be used by malware developers to hide malicious content from auditors. This may be an indication of potentially malicious activity being performed by the Flash application.
Example:
ASNative(100, 4)("Hi"); //is equivalent to trace("Hi");
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 676
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[10] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 676
[11] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP2060.4 CAT II
[12] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP2060.4 CAT II
[13] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP2060.4 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP2060.4 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP2060.4 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP2060.4 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP2060.4 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
desc.dynamic.actionscript.dangerous_function_asnative
Abstract
Functions that cannot be used safely should never be used.
Explanation
Certain functions behave in dangerous ways regardless of how they are used. Functions in this category were often implemented without taking security concerns into account.

References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 676
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002824
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 18-0-5
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-16 Memory Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-16 Memory Protection
[12] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[13] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[26] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 676
[27] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP2060.4 CAT II, APP3590.2 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP2060.4 CAT II, APP3590.2 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP2060.4 CAT II, APP3590.2 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP2060.4 CAT II, APP3590.2 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP2060.4 CAT II, APP3590.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP2060.4 CAT II, APP3590.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP2060.4 CAT II, APP3590.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002590 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002590 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002590 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002590 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002590 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002590 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002590 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002590 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002590 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002590 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002590 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002590 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002590 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002590 CAT I
[48] Standards Mapping - Web Application Security Consortium Version 2.00 Buffer Overflow (WASC-07)
[49] Standards Mapping - Web Application Security Consortium 24 + 2 Buffer Overflow
desc.semantic.cpp.dangerous_function_strcpy
Abstract
Functions that cannot be used safely should never be used.
Explanation
Certain functions behave dangerously regardless of how they are used. Functions in this category were often implemented without consideration for security.

Example 1: Given the URL http://www.example.com/index.php?param=..., the following snippet of php within index.php will print the value of the URL parameter param (passed in-place of the "...") to the screen if it matches the POSIX regular expression '^[[:alnum:]]*$' representing "zero or more alphanumeric characters":

<?php
$pattern = '^[[:alnum:]]*$';
$string = $_GET['param'];
if (ereg($pattern, $string)) {
echo($string);
}
?>


While Example 1 operates as expected with alphanumeric input, because the unsafe ereg() function is used to validate tainted input, it is possible to carry out a cross-site scripting (XSS) attack via null byte injection. By passing a value for param containing a valid alphanumeric string followed by a null byte and then a <script> tag (e.g. "Hello123%00<script>alert("XSS")</script>"), ereg($pattern, $string) will still return true, as the ereg() function ignores everything following a null byte character when reading the input string (left-to-right). In this example, this means that the injected <script> tag following the null byte will be displayed to the user and evaluated.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 676
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[13] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[16] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 676
[17] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP2060.4 CAT II, APP3590.2 CAT I
[18] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP2060.4 CAT II, APP3590.2 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP2060.4 CAT II, APP3590.2 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP2060.4 CAT II, APP3590.2 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP2060.4 CAT II, APP3590.2 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP2060.4 CAT II, APP3590.2 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP2060.4 CAT II, APP3590.2 CAT II
desc.semantic.php.dangerous_function_unsafe_regular_expression
Abstract
The function xp_cmdshell cannot be used safely. It should not be used.
Explanation
Certain functions behave in dangerous ways regardless of how they are used. The function xp_cmdshell launches a Windows command shell to execute the provided command string. The command executes either in the default system or a provided proxy context. However, there is no way to limit a user to prespecified set of privileged operations and any privilege grant opens up the user to execute any command string.
References
[1] xp_cmdshell
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - Common Weakness Enumeration CWE ID 242
[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[9] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 7.1.2
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 7.1.2
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 7.1.2
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 7.1.2
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 7.2.2
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[16] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control
[18] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 676
[19] Standards Mapping - Web Application Security Consortium Version 2.00 OS Commanding (WASC-31)
[20] Standards Mapping - Web Application Security Consortium 24 + 2 OS Commanding
desc.semantic.sql.dangerous_function_xp_cmdshell
Abstract
The method has been annotated as dangerous. All uses of this method will be flagged as issues.
Explanation
The annotation FortifyDangerous has been applied to this method. This is used to indicate that it is dangerous and all uses should be examined for safety.
desc.structural.java.dangerous_method
Abstract
The variable is of a type which has been annotated as dangerous.
Explanation
The annotation FortifyDangerous has been applied to this type. This is used to indicate that it is dangerous and all uses should be examined for safety.

desc.structural.java.dangerous_class_variable