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
Permitting users to upload files can allow attackers to inject dangerous content or malicious code to run on the server.
Explanation
Regardless of the language in which a program is written, the most devastating attacks often involve remote code execution, whereby an attacker succeeds in executing malicious code in the program's context. If attackers are allowed to upload files to a directory that is accessible from the Web and cause these files to be passed to a code interpreter (e.g. JSP/ASPX/PHP), then they can cause malicious code contained in these files to execute on the server.

The following code receives an uploaded file and assigns it to the posted object. FileUpload is of type System.Web.UI.HtmlControls.HtmlInputFile.
Example:

HttpPostedFile posted = FileUpload.PostedFile;

Even if a program stores uploaded files under a directory that isn't accessible from the Web, attackers might still be able to leverage the ability to introduce malicious content into the server environment to mount other attacks. If the program is susceptible to path manipulation, command injection, or dangerous file inclusion vulnerabilities, then an attacker might upload a file with malicious content and cause the program to read or execute it by exploiting another vulnerability.
References
[1] Alla Bezroutchko Secure file upload in PHP web applications
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 5
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - Common Weakness Enumeration CWE ID 434
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [16] CWE ID 434
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [15] CWE ID 434
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [10] CWE ID 434
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [10] CWE ID 434
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [10] CWE ID 434
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[14] Standards Mapping - FIPS200 SI
[15] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 12.2.1 File Integrity Requirements (L2 L3), 12.5.2 File Download Requirements (L1 L2 L3), 13.1.5 Generic Web Service Security Verification Requirements (L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective C.3.4 - Web Software Attack Mitigation
[37] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 434
[38] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 434
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.semantic.dotnet.often_misused_file_upload
Abstract
Permitting users to upload files can allow attackers to inject dangerous content or malicious code to run on the server.
Explanation
Regardless of the language a program is written in, the most devastating attacks often involve remote code execution, whereby an attacker succeeds in executing malicious code in the program's context. If attackers are allowed to upload files to a directory that is accessible from the Web and cause these files to be passed to a code interpreter (e.g. JSP/ASPX/PHP), then they can cause malicious code contained in these files to execute on the server.

Example: The following Spring MVC controller class has a parameter than can be used to handle uploaded files.

@Controller
public class MyFormController {
...
@RequestMapping("/test")
public String uploadFile (org.springframework.web.multipart.MultipartFile file) {
...
} ...
}


Even if a program stores uploaded files under a directory that isn't accessible from the Web, attackers might still be able to leverage the ability to introduce malicious content into the server environment to mount other attacks. If the program is susceptible to path manipulation, command injection, or dangerous file inclusion vulnerabilities, then an attacker might upload a file with malicious content and cause the program to read or execute it by exploiting another vulnerability.
References
[1] Alla Bezroutchko Secure file upload in PHP web applications
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 5
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - Common Weakness Enumeration CWE ID 434
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [16] CWE ID 434
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [15] CWE ID 434
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [10] CWE ID 434
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [10] CWE ID 434
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [10] CWE ID 434
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[14] Standards Mapping - FIPS200 SI
[15] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 12.2.1 File Integrity Requirements (L2 L3), 12.5.2 File Download Requirements (L1 L2 L3), 13.1.5 Generic Web Service Security Verification Requirements (L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective C.3.4 - Web Software Attack Mitigation
[37] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 434
[38] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 434
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.structural.java.often_misused_file_upload_spring
Abstract
Permitting users to upload files can allow attackers to inject dangerous content or malicious code to run on the server.
Explanation
Regardless of the language in which a program is written, the most devastating attacks often involve remote code execution, whereby an attacker succeeds in executing malicious code in the program's context. If attackers are allowed to upload files to a directory that is accessible from the Web and cause these files to be passed to the PHP interpreter, then they can cause malicious code contained in these files to execute on the server.

Example 1: The following code processes uploaded files and moves them into a directory under the Web root. Attackers may upload malicious PHP source files to this program and subsequently request them from the server, which will cause them to be executed by the PHP interpreter.


<?php
$udir = 'upload/'; // Relative path under Web root
$ufile = $udir . basename($_FILES['userfile']['name']);
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $ufile)) {
echo "Valid upload received\n";
} else {
echo "Invalid upload rejected\n";
} ?>


Even if a program stores uploaded files under a directory that isn't accessible from the Web, attackers might still be able to leverage the ability to introduce malicious content into the server environment to mount other attacks. If the program is susceptible to path manipulation, command injection, or remote include vulnerabilities, then an attacker might upload a file with malicious content and cause the program to read or execute it by exploiting another vulnerability.
References
[1] M. Achour et al. PHP Manual
[2] PHP Security Consortium PhpSecInfo Test Information
[3] Alla Bezroutchko Secure file upload in PHP web applications
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 5
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - Common Weakness Enumeration CWE ID 434
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [16] CWE ID 434
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [15] CWE ID 434
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [10] CWE ID 434
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [10] CWE ID 434
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [10] CWE ID 434
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[16] Standards Mapping - FIPS200 SI
[17] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[20] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[21] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[22] Standards Mapping - OWASP Top 10 2010 A1 Injection
[23] Standards Mapping - OWASP Top 10 2013 A1 Injection
[24] Standards Mapping - OWASP Top 10 2017 A1 Injection
[25] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 12.2.1 File Integrity Requirements (L2 L3), 12.5.2 File Download Requirements (L1 L2 L3), 13.1.5 Generic Web Service Security Verification Requirements (L2 L3)
[27] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective C.3.4 - Web Software Attack Mitigation
[39] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 434
[40] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 434
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.semantic.php.often_misused_file_upload
Abstract
Permitting users to upload files can allow attackers to inject dangerous content or malicious code to run on the server.
Explanation
Regardless of the language in which a program is written, the most devastating attacks often involve remote code execution, whereby an attacker succeeds in executing malicious code in the program's context. If attackers are allowed to upload files to a directory that is accessible from the Web and cause these files to be passed to the Python interpreter, then they can cause malicious code contained in these files to execute on the server.

Example 1: The following code processes uploaded files and moves them into a directory under the web root. Attackers may upload malicious files to this program and subsequently request them from the server.


from django.core.files.storage import default_storage
from django.core.files.base import File
...
def handle_upload(request):
files = request.FILES
for f in files.values():
path = default_storage.save('upload/', File(f))
...


Even if a program stores uploaded files under a directory that isn't accessible from the Web, attackers might still be able to leverage the ability to introduce malicious content into the server environment to mount other attacks. If the program is susceptible to path manipulation, command injection, or remote include vulnerabilities, then an attacker might upload a file with malicious content and cause the program to read or execute it by exploiting another vulnerability.
References
[1] Django Foundation File Uploads
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 5
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - Common Weakness Enumeration CWE ID 434
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [16] CWE ID 434
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [15] CWE ID 434
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [10] CWE ID 434
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [10] CWE ID 434
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [10] CWE ID 434
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[14] Standards Mapping - FIPS200 SI
[15] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 12.2.1 File Integrity Requirements (L2 L3), 12.5.2 File Download Requirements (L1 L2 L3), 13.1.5 Generic Web Service Security Verification Requirements (L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective C.3.4 - Web Software Attack Mitigation
[37] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 434
[38] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 434
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.structural.python.often_misused_file_upload
Abstract
Permitting users to upload files can allow attackers to inject dangerous content or malicious code to run on the server.
Explanation
Regardless of the language in which a program is written, the most devastating attacks often involve remote code execution, whereby an attacker succeeds in executing malicious code in the program's context. If attackers are allowed to upload files to a publicly executable directory, then they can cause malicious code contained in these files to execute on the server.

Even if a program stores uploaded files under a directory that isn't publicly accessible, attackers might still be able to leverage the ability to introduce malicious content into the server environment to mount other attacks. If the program is susceptible to path manipulation, command injection, or remote include vulnerabilities, then an attacker might upload a file with malicious content and cause the program to read or execute it by exploiting another vulnerability.
References
[1] Alla Bezroutchko Secure file upload in PHP web applications
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 5
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - Common Weakness Enumeration CWE ID 434
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [16] CWE ID 434
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [15] CWE ID 434
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [10] CWE ID 434
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [10] CWE ID 434
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [10] CWE ID 434
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[14] Standards Mapping - FIPS200 SI
[15] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 12.2.1 File Integrity Requirements (L2 L3), 12.5.2 File Download Requirements (L1 L2 L3), 13.1.5 Generic Web Service Security Verification Requirements (L2 L3)
[25] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective C.3.4 - Web Software Attack Mitigation
[37] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 434
[38] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 434
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.structural.ruby.often_misused_file_upload
Abstract
Permitting users to upload files can allow attackers to inject dangerous content or malicious code to run on the server.
Explanation
Regardless of the language in which a program is written, the most devastating attacks often involve remote code execution, whereby an attacker succeeds in executing malicious code in the program's context. If attackers are allowed to upload files to a directory that is accessible from the Web and cause these files to be passed to a code interpreter (e.g. JSP/ASPX/PHP), then they can cause malicious code contained in these files to execute on the server.
Even if a program stores uploaded files under a directory that isn't accessible from the Web, attackers might still be able to leverage the ability to introduce malicious content into the server environment to mount other attacks. If the program is susceptible to path manipulation, command injection, or dangerous file inclusion vulnerabilities, then an attacker might upload a file with malicious content and cause the program to read or execute it by exploiting another vulnerability.

An <input> tag of type file indicates the program accepts file uploads.
Example:

<input type="file">
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 5
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 434
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [16] CWE ID 434
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [15] CWE ID 434
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [10] CWE ID 434
[10] Standards Mapping - Common Weakness Enumeration Top 25 2022 [10] CWE ID 434
[11] Standards Mapping - Common Weakness Enumeration Top 25 2023 [10] CWE ID 434
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[13] Standards Mapping - FIPS200 SI
[14] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[17] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[19] Standards Mapping - OWASP Top 10 2010 A1 Injection
[20] Standards Mapping - OWASP Top 10 2013 A1 Injection
[21] Standards Mapping - OWASP Top 10 2017 A1 Injection
[22] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[23] Standards Mapping - OWASP Application Security Verification Standard 4.0 12.2.1 File Integrity Requirements (L2 L3), 12.5.2 File Download Requirements (L1 L2 L3), 13.1.5 Generic Web Service Security Verification Requirements (L2 L3)
[24] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.3
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective C.3.4 - Web Software Attack Mitigation
[36] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 434
[37] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 434
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.content.html.often_misused_file_upload
Abstract
Unsafe use of Flash storage objects could lead to unauthorized client-side access to sensitive content.
Explanation
Local Storage Objects (LSO) are a mechanism provided by the Flash platform to persistently store data on the client machine. By default the Flash security model restricts access to a shared object based on the domain hosting the SWF file that created it, the path of the SWF file and whether the creating SWF file was hosted on HTTP or HTTPS. The localpath property on a shared object specifies the path of the SWFs that have access to a shared object. So a shared object created by http://www.example.com/dir1/dir2/sample.swf can be configured to be accessible by any SWF at http://www.example.com/dir1 by setting its localPath property to http://www.example.com/dir1.
Setting the localPath value to "/", all SWF files on that domain gain access to the shared object. On a domain hosting SWF applications from multiple parties, such a setting could lead to unauthorized data access.

If an application uses "/" to set the localPath inside a SharedObject.getLocal() call, the shared object is configured to be accessible by all SWFs on the domain exposing the application to information theft risks.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3
[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 - DISA Control Correlation Identifier Version 2 CCI-001090
[6] Standards Mapping - FIPS200 MP
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-4 Information in Shared Resources (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-4 Information in Shared System Resources
[10] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[11] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[12] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[13] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[14] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[15] Standards Mapping - OWASP Mobile 2024 M9 Insecure Data Storage
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 6.1 - Sensitive Data Protection
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 6.1 - Sensitive Data Protection
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 6.1 - Sensitive Data Protection
[27] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002380 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002380 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002380 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002380 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002380 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002380 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002380 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002380 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002380 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002380 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002380 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002380 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002380 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002380 CAT II
[41] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[42] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dynamic.actionscript.often_misused_flash_storage_object
Abstract
Attackers may bypass server protections against dangerous HTTP verbs using override techniques.
Explanation
In order to protect access to various resources, web servers may be configured to prevent the usage of specific HTTP verbs. However, some web frameworks provide a way to override the HTTP verb by using HTTP request headers. This feature is typically used when a web or proxy server restricts certain verbs, but the application needs to use them, especially in RESTful services. However, it is possible for a malicious user to take advantage of this feature. Doing so may allow the attacker to perform unintended actions on protected resources in the web application.

The attack works by using a trusted HTTP verb such as GET or POST, but adds request headers such as X-HTTP-Method, X-HTTP-Method-Override, or X-Method-Override to provide a restricted verb such as PUT or DELETE. Doing so will force the request to be interpreted by the target application using the verb in the request header instead of the actual HTTP verb. In certain cases, the restricted verb may also be used in query or post parameters instead of a request header.
References
[1] MSDN Microsoft
[2] ExpressJS ExpressJS
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 749
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000381
[11] Standards Mapping - FIPS200 AC
[12] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[15] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[16] Standards Mapping - OWASP Top 10 2007 A10 Failure to Restrict URL Access
[17] Standards Mapping - OWASP Top 10 2010 A8 Failure to Restrict URL Access
[18] Standards Mapping - OWASP Top 10 2013 A7 Missing Function Level Access Control
[19] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[20] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[21] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.5.1 Validate HTTP Request Header Requirements (L1 L2 L3)
[22] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[30] 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
[31] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 676
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3110 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3110 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3110 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001500 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001500 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001500 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001500 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001500 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001500 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001500 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001500 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001500 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001500 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001500 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001500 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001500 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001500 CAT II
[49] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
[50] Standards Mapping - Web Application Security Consortium 24 + 2 Abuse of Functionality
desc.dynamic.xtended_preview.often_misused_http_method_override
Abstract
Insecure handling of login information can allow attackers to circumvent the application's authentication system.
Explanation
Poorly written login forms could lead to the following vulnerabilities:

1. Theft of credential information
a. Login forms designed to use the GET HTTP method can reveal sensitive information to attackers in the query string.
b. Transmission of login information in cleartext leaves it vulnerable to information theft.
c. Serving login forms over non secure connection could allow an attacker to intercept and tamper the login form itself thus circumventing any protections offered by the original login form
d. Processing of unvalidated data in the page containing the login form could allow attackers to install malicious scripts and capture sensitive information
2. Authentication bypass
a. Failing to validate data submitted by the user via a login form could leave the application vulnerable to SQL Injection attacks allowing an attacker to completely bypass the authentication system
3. Session hijacking
a. In the absence of adequate protections against Cross-Site Request Forgery and Cross-Frame Scripting vulnerabilities, attackers can hijack legitimate user sessions.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 311
[6] Standards Mapping - FIPS200 SC
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-8 Transmission Confidentiality and Integrity (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-8 Transmission Confidentiality and Integrity
[10] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[11] Standards Mapping - OWASP Top 10 2007 A9 Insecure Communications
[12] Standards Mapping - OWASP Top 10 2010 A9 Insufficient Transport Layer Protection
[13] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[14] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[15] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[16] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 8.1.6 General Data Protection (L3)
[17] Standards Mapping - OWASP Mobile 2014 M3 Insufficient Transport Layer Protection
[18] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 8.4
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 4.1, Requirement 6.3.1.4, Requirement 6.5.9, Requirement 8.4
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 4.1, Requirement 6.5.4, Requirement 8.4
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 6.2 - Sensitive Data Protection
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 6.2 - Sensitive Data Protection
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 6.2 - Sensitive Data Protection, Control Objective C.4.1 - Web Software Communications
[30] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 311
[31] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3330 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3330 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3330 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3330 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3330 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3330 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3330 CAT I
desc.dynamic.xtended_preview.often_misused_login
Abstract
A MAC address is intended to be used as a network identifier. Since a MAC address permanently identifies a device, all apps using it as a user identifier will have the same ID value. Hence, by correlating information from various apps, it is possible to identify a device and its user, threatening user privacy.
Explanation
A MAC address is a unique identifier that is assigned to hardware network interfaces. These addresses are unique to every computer or mobile device and cannot be modified. Hence, a MAC address can be used to uniquely identify a given device, indirectly identifying the person using the device as well. MAC addresses should only be used by network components to connect the device to the network. Some applications tend to use it to identify a user in order to track and personalize the user's experience.

Typically, a MAC address is 6 bytes long, and can be represented in 6 groups, each group composed of two hexadecimal digits. The groups can be separated by either a colon or a hyphen; for example,

65:4A:9D:D8:98:F3 (or)
65-4A-9D-D8-98-F3
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[5] Standards Mapping - CIS Kubernetes Benchmark partial
[6] Standards Mapping - Common Weakness Enumeration CWE ID 359
[7] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001090
[11] Standards Mapping - General Data Protection Regulation (GDPR) Privacy Violation
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-4 Information in Shared Resources (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-4 Information in Shared System Resources
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[16] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[17] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[18] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.2.2 Client-side Data Protection (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[19] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[20] Standards Mapping - OWASP Mobile 2024 M6 Inadequate Privacy Controls
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1
[24] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002380 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002380 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002380 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002380 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002380 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002380 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002380 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002380 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002380 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002380 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002380 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002380 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002380 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002380 CAT II
[38] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[39] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dynamic.xtended_preview.often_misused_mac_address
Abstract
Template languages should not be mixed to prevent working around cross-site scripting protections.
Explanation
When you mix templating engines it means that protections that were previously implemented for one may no longer work, or be valid. In the most benign version of this, it may lead to functionality not working as expected, but this also may allow malicious users to get around protections in the engine that lead to cross-site scripting vulnerabilities.

Example 1: In the following code an AngularJS module is configured to use "[[" and "]]" for expression delimiters instead of the default.


myModule.config(function($interpolateProvider){
$interpolateProvider.startSymbol("[[");
$interpolateProvider.endSymbol("]]");
});


This could lead to the other template engine performing validation to escape the expressions, which may not be compatible with AngularJS expressions, potentially leading to users being able to bypass regular validation and run their own code within the browser.
References
[1] AngularJS $interpolateProvider documentation Google
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[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 - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
desc.structural.javascript.often_misused_mixing_template_languages
Abstract
The target mobile application sends data that looks like a Universal Device Identifier (UDID) in a request.
Explanation
The mobile application includes data that matches the pattern of a Universal Device Identifier (UDID) in a request to an external host. A UDID is a static construct used to uniquely identify one mobile device from another. UDID implementations may differ across platforms. For example, while iOS uses a 20-byte hex string, Android uses the device's embedded IMEI or MEID number. [1, 2]

A device's UDID is completely persistent across wipes, and can therefore be used to personalize a user's preferences and behavior across multiple apps as long as he or she remains the sole owner and user of the device. As this is not a completely reliable assumption to make, one should not use a device's UDID for this purpose.

Furthermore, as UDIDs are completely persistent across wipes and cannot be changed, associating a user's name or other identifying information with the UDID of his or her device would present itself as a privacy violation should this data ever become public. Apple deprecated API access to its devices' UDIDs in iOS 5 for this purpose admid increasing concerns within the research community. [3]
References
[1] Thompson, M. NSUUID / CFUUIDRef / UIDevice -uniqueIdentifier / -identifierForVendor NSHipster
[2] Telephony Manager | Android Developers Google
[3] Foresman, C. Ask Ars: What's the big deal with iPhone UDIDs? Ars Technica
[4] NSUUID Class Reference Apple
[5] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[9] Standards Mapping - CIS Kubernetes Benchmark complete
[10] Standards Mapping - Common Weakness Enumeration CWE ID 359
[11] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[12] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[13] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001090
[15] Standards Mapping - General Data Protection Regulation (GDPR) Privacy Violation
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-4 Information in Shared Resources (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-4 Information in Shared System Resources
[18] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[19] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.2.2 Client-side Data Protection (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 10.2.1 Malicious Code Search (L2 L3)
[23] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[24] Standards Mapping - OWASP Mobile 2024 M6 Inadequate Privacy Controls
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1
[30] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002380 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002380 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002380 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002380 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002380 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002380 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002380 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002380 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002380 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002380 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002380 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002380 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002380 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002380 CAT II
[44] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[45] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dynamic.xtended_preview.often_misused_mobile_udid