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
Improper use of the chroot() system call could allow attackers to escape a chroot jail.
Explanation
The chroot() system call allows a process to change its perception of the root directory of the file system. After properly invoking chroot(), a process cannot access any files outside the directory tree defined by the new root directory. Such an environment is called a chroot jail and is commonly used to prevent the possibility that a processes could be subverted and used to access unauthorized files. For instance, many FTP servers run in chroot jails to prevent an attacker who discovers a new vulnerability in the server from being able to download the password file or other sensitive files on the system.

Improper use of chroot() may allow attackers to escape from the chroot jail. The chroot() function call does not change the process's current working directory, so relative paths may still refer to file system resources outside of the chroot jail after chroot() has been called.

Example 1: Consider the following source code from a (hypothetical) FTP server:


chroot("/var/ftproot");
...
fgets(filename, sizeof(filename), network);
localfile = fopen(filename, "r");
while ((len = fread(buf, 1, sizeof(buf), localfile)) != EOF) {
fwrite(buf, 1, sizeof(buf), network);
}
fclose(localfile);


This code is responsible for reading a filename from the network, opening the corresponding file on the local machine, and sending the contents over the network. This code could be used to implement the FTP GET command. The FTP server calls chroot() in its initialization routines in an attempt to prevent access to files outside of /var/ftproot. But because the server fails to change the current working directory by calling chdir("/"), an attacker could request the file "../../../../../etc/passwd" and obtain a copy of the system password file.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] A. Chuvakin Using Chroot Securely
desc.semantic.cpp.directory_restriction
Abstract
The program violates the Enterprise JavaBeans specification by using AWT/Swing.
Explanation
The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container [1].

In this case, the program violates the following EJB guideline:

"An enterprise bean must not use the AWT functionality to attempt to output information to a display, or to input information from a keyboard."

A requirement that the specification justifies in the following way:

"Most servers do not allow direct interaction between an application program and a keyboard/display attached to the server system."
References
[1] The Enterprise JavaBeans 2.1 Specification Sun Microsystems
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 6
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 575
desc.structural.java.ejb_bad_practices_use_of_awt_swing
Abstract
The program violates the Enterprise JavaBeans specification by using the class loader.
Explanation
The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container [1].

In this case, the program violates the following EJB guideline:

"The enterprise bean must not attempt to create a class loader; obtain the current class loader; set the context class loader; set security manager; create a new security manager; stop the JVM; or change the input, output, and error streams."

A requirement that the specification justifies in the following way:

"These functions are reserved for the EJB container. Allowing the enterprise bean to use these functions could compromise security and decrease the container's ability to properly manage the runtime environment."
References
[1] The Enterprise JavaBeans 2.1 Specification Sun Microsystems
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 6
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 578
desc.structural.java.ejb_bad_practices_use_of_classloader
Abstract
The program violates the Enterprise JavaBeans specification by using the java.io package.
Explanation
The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container [1].

In this case, the program violates the following EJB guideline:

"An enterprise bean must not use the java.io package to attempt to access files and directories in the file system."

A requirement that the specification justifies in the following way:

"The file system APIs are not well-suited for business components to access data. Business components should use a resource manager API, such as JDBC, to store data."
References
[1] The Enterprise JavaBeans 2.1 Specification Sun Microsystems
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 6
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 576
desc.structural.java.ejb_bad_practices_use_of_java_io
Abstract
The program violates the Enterprise JavaBeans specification by using sockets.
Explanation
The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container [1].

In this case, the program violates the following EJB guideline:

"An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or use a socket for multicast."

A requirement that the specification justifies in the following way:

"The EJB architecture allows an enterprise bean instance to be a network socket client, but it does not allow it to be a network server. Allowing the instance to become a network server would conflict with the basic function of the enterprise bean-- to serve the EJB clients."
References
[1] The Enterprise JavaBeans 2.1 Specification Sun Microsystems
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 6
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 577
desc.structural.java.ejb_bad_practices_use_of_sockets
Abstract
The program violates the Enterprise JavaBeans specification by using thread synchronization primitives.
Explanation
The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container [1].

In this case, the program violates the following EJB guideline:

"An enterprise bean must not use thread synchronization primitives to synchronize execution of multiple instances."

A requirement that the specification justifies in the following way:

"This rule is required to ensure consistent runtime semantics because while some EJB containers may use a single JVM to execute all enterprise bean's instances, others may distribute the instances across multiple JVMs."
References
[1] The Enterprise JavaBeans 2.1 Specification Sun Microsystems
[2] THI01-J. Do not invoke ThreadGroup methods CERT
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 6
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 574
desc.structural.java.ejb_bad_practices_use_of_synchronization_primitives
Abstract
Constructing a FileResponse instance with user input could allow an attacker to download application binaries or view arbitrary files within protected directories.
Explanation
A file disclosure occurs when:
1. Data enters a program from an untrusted source.


2. The data is used to dynamically construct a path.

Example 1: The following code takes untrusted data and uses it to open a file that is returned to the user.


from django.http import FileResponse
...
def file_disclosure(request):
path = request.GET['returnURL']
return FileResponse(open(path, 'rb'))
...


If an attacker provided a URL with the request parameter matching a sensitive file location, they would be able to view that file. For example, "http://www.yourcorp.com/webApp/logic?returnURL=settings.py" would allow them to view the "settings.py" of the application.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.1
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 552
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[14] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[15] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[16] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[17] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[18] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.12.1 Secure File Upload Architectural Requirements (L2 L3), 12.5.1 File Download Requirements (L1 L2 L3)
[20] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[32] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 073
[33] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002560 CAT I
[47] Standards Mapping - Web Application Security Consortium Version 2.00 URL Redirector Abuse (WASC-38)
desc.dataflow.python.file_disclosure_django