120 items found
Weaknesses
Abstract
Allowing user input to directly alter file permissions might enable an attacker to access otherwise protected system resources.
Explanation
File permission manipulation errors occur when any of the following conditions are met:

1. An attacker might specify a path used in an operation that modifies permissions on the file system.

2. An attacker might specify the permissions assigned by an operation on the file system.

Example 1: The following code uses input from system environment variables to set file permissions. If attackers can alter the system environment variables, they might use the program to gain access to files manipulated by the program. If the program is also vulnerable to path manipulation, an attacker might use this vulnerability to access arbitrary files on system.


permissions := strconv.Atoi(os.Getenv("filePermissions"));
fMode := os.FileMode(permissions)
os.chmod(filePath, fMode);
...
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[8] Standards Mapping - Common Weakness Enumeration CWE ID 264, CWE ID 732
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[13] Standards Mapping - FIPS200 AC
[14] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[17] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[18] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.3 General Access Control Design (L1 L2 L3), 4.1.5 General Access Control Design (L1 L2 L3), 4.2.1 Operation Level Access Control (L1 L2 L3), 4.3.3 Other Access Control Considerations (L2 L3), 7.3.3 Log Protection Requirements (L2 L3)
[20] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[21] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[22] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 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 3.2 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[33] 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
[34] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[35] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[36] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[37] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.golang.file_permission_manipulation
Abstract
Allowing user input to directly alter file permissions may enable an attacker to access otherwise protected system resources.
Explanation
File permission manipulation errors occur when any of the following conditions are met:

1. An attacker is able to specify a path used in an operation that modifies permissions on the file system.

2. An attacker is able to specify the permissions assigned by an operation on the file system.

Example 1: The following code uses input from system properties to set the default permission mask. If attackers can alter the system properties, they may use the program to gain access to files manipulated by the program. If the program is also vulnerable to path manipulation, an attacker may use this vulnerability to access arbitrary files on system.


String permissionMask = System.getProperty("defaultFileMask");
Path filePath = userFile.toPath();
...
Set<PosixFilePermission> perms = PosixFilePermissions.fromString(permissionMask);
Files.setPosixFilePermissions(filePath, perms);
...
References
[1] FIO01-J. Create files with appropriate access permissions CERT
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark complete
[9] Standards Mapping - Common Weakness Enumeration CWE ID 264, CWE ID 732
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[14] Standards Mapping - FIPS200 AC
[15] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[18] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[19] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.3 General Access Control Design (L1 L2 L3), 4.1.5 General Access Control Design (L1 L2 L3), 4.2.1 Operation Level Access Control (L1 L2 L3), 4.3.3 Other Access Control Considerations (L2 L3), 7.3.3 Log Protection Requirements (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[34] 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
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.file_permission_manipulation
Abstract
Allowing user input to directly alter file permissions may enable an attacker to access otherwise protected system resources.
Explanation
File permission manipulation errors occur when any of the following conditions are met:

1. An attacker is able to specify a path used in an operation that modifies permissions on the file system.

2. An attacker is able to specify the permissions assigned by an operation on the file system.

Example: The following code is designed to set proper file permissions for users uploading Web pages through FTP. It uses input from an HTTP request to mark a file as viewable for external users.


$rName = $_GET['publicReport'];
chmod("/home/". authenticateUser . "/public_html/" . rName,"0755");
...


However, if an attacker provides a malicious value for publicReport, such as "../../localuser/public_html/.htpasswd", the application will make the specified file readable to the attacker.

Example 2: The following code uses input from a configuration file to set the default permission mask. If attackers can alter the configuration file, they can use the program to gain access to files manipulated by the program. If the program is also vulnerable to path manipulation, an attacker may use this vulnerability to access arbitrary files on system.


...
$mask = $CONFIG_TXT['perms'];
chmod($filename,$mask);
...
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark complete
[9] Standards Mapping - Common Weakness Enumeration CWE ID 264, CWE ID 732
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[14] Standards Mapping - FIPS200 AC
[15] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[18] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[19] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.3 General Access Control Design (L1 L2 L3), 4.1.5 General Access Control Design (L1 L2 L3), 4.2.1 Operation Level Access Control (L1 L2 L3), 4.3.3 Other Access Control Considerations (L2 L3), 7.3.3 Log Protection Requirements (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[34] 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
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.php.file_permission_manipulation
Abstract
Allowing user input to directly alter file permissions may enable an attacker to access otherwise protected system resources.
Explanation
File permission manipulation errors occur when any of the following conditions are met:

1. An attacker is able to specify a path used in an operation that modifies permissions on the file system.

2. An attacker is able to specify the permissions assigned by an operation on the file system.

Example 1: The following code uses input from system environment variables to set file permissions. If attackers can alter the system environment variables, they may use the program to gain access to files manipulated by the program. If the program is also vulnerable to path manipulation, an attacker may use this vulnerability to access arbitrary files on system.


permissions = os.getenv("filePermissions");
os.chmod(filePath, permissions);
...
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark complete
[8] Standards Mapping - Common Weakness Enumeration CWE ID 264, CWE ID 732
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[13] Standards Mapping - FIPS200 AC
[14] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[15] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[16] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[17] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[18] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.3 General Access Control Design (L1 L2 L3), 4.1.5 General Access Control Design (L1 L2 L3), 4.2.1 Operation Level Access Control (L1 L2 L3), 4.3.3 Other Access Control Considerations (L2 L3), 7.3.3 Log Protection Requirements (L2 L3)
[20] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[21] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[22] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 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 3.2 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[33] 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
[34] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[35] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[36] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[37] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.python.file_permission_manipulation
Abstract
Allowing user input to directly alter file permissions may enable an attacker to access otherwise protected system resources.
Explanation
File permission manipulation errors occur when any of the following conditions are met:

1. An attacker is able to specify a path used in an operation that modifies permissions on the file system.

2. An attacker is able to specify the permissions assigned by an operation on the file system.

Example: The following code is designed to set proper file permissions for users uploading Web pages through FTP. It uses input from an HTTP request to mark a file as viewable for external users.


...
rName = req['publicReport']
File.chmod("/home/#{authenticatedUser}/public_html/#{rName}", "0755")
...


However, if an attacker provides a malicious value for publicReport, such as "../../localuser/public_html/.htpasswd", the application will make the specified file readable to the attacker.

Example 2: The following code uses input from a configuration file to set the default permission mask. If attackers can alter the configuration file, they may use the program to gain access to files manipulated by the program. If the program is also vulnerable to path manipulation, an attacker may use this vulnerability to access arbitrary files on system.


...
mask = config_params['perms']
File.chmod(filename, mask)
...
References
[1] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark complete
[9] Standards Mapping - Common Weakness Enumeration CWE ID 264, CWE ID 732
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [15] CWE ID 732
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [16] CWE ID 732
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [22] CWE ID 732
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[14] Standards Mapping - FIPS200 AC
[15] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[18] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[19] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 4.1.3 General Access Control Design (L1 L2 L3), 4.1.5 General Access Control Design (L1 L2 L3), 4.2.1 Operation Level Access Control (L1 L2 L3), 4.3.3 Other Access Control Considerations (L2 L3), 7.3.3 Log Protection Requirements (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[34] 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
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 732
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 732
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 732
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.ruby.file_permission_manipulation
Abstract
Hardcoding sensitive information in binary SWF files might lead to information theft.
Explanation
The misconception that any information stored in the binary SWF files is safe from unauthorized access often leads to programmers embedding sensitive information like passwords, cryptographic data, and sensitive business logic in them. Attackers can easily decompile binary SWF files and steal the sensitive information. This might lead to a compromise the system.
Example:

if (password eq '783-1') {
getURL('http://.../client_pages/.../783.html', '');
}
else {
if (password eq '771-2 Update') {
getURL('http://.../client_pages/.../771.html', '');
}
else {
if (password eq '7990') {
getURL('http://.../client_pages/.../799.html', '');
}
}

By decompiling the binary SWF, an attacker can not only gain access to the passwords but also to locations of unexposed URLs.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[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 200, CWE ID 318, CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200, [13] CWE ID 287, [19] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200, [14] CWE ID 287, [20] CWE ID 798
[8] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798, [20] CWE ID 200
[9] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002367, CCI-003109
[12] Standards Mapping - FIPS200 MP
[13] Standards Mapping - General Data Protection Regulation (GDPR) Privacy Violation
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SA-4 Acquisition Process (P1), SC-18 Mobile Code (P2)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SA-4 Acquisition Process, SC-18 Mobile Code
[16] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[17] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[18] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[19] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[20] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[21] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.1.1 Data Classification (L2 L3), 6.1.2 Data Classification (L2 L3), 6.1.3 Data Classification (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 8.1.6 General Data Protection (L3), 8.2.2 Client-side Data Protection (L1 L2 L3), 8.3.4 Sensitive Private Data (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)
[22] Standards Mapping - OWASP Mobile 2024 M6 Inadequate Privacy Controls
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.3, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.4, Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.4, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.4, Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.4, Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.4, Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.4, Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.5.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.6.2
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective A.2.3 - Cardholder Data Protection, Control Objective 7 - Use of Cryptography
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective A.2.3 - Cardholder Data Protection, Control Objective 7 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective A.2.3 - Cardholder Data Protection, Control Objective 7 - Use of Cryptography
[34] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[35] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3350 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3350 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dynamic.actionscript.flash_bad_practices_hardcoded_sensitive_information
Abstract
Granting overly excessive permissions might allow a malicious flash application to transmit sensitive information to an arbitrary remote site.
Explanation
When a Flash application is embedded within HTML, there are several flags that inform the Flash player if the SWF file can have access to content from the browser or from the network.
- AllowScriptAccess
This flag tells the Flash player to allow the SWF to communicate with the browser and HTML DOM using ExternalInterface, fscommand or getURL.
- AllowNetworkingAccess
This flag informs the Flash player that it is allowed to make networking calls like XML.load, loadVariables, LoadVars.load etc. If a Flash application should not communicate with the browser or needs to make any networking calls, the AllowNetworkingAccess tag must be set to "none".
1. If a Flash application should not communicate with the browser or needs to make any networking calls, the AllowNetworkingAccess tag must be set to "none".
2. If a Flash application should not communicate with the browser but needs to make networking calls, the AllowNetworkingAccess tag should be set to "internal".
3. If a Flash application needs to communicate with both the browser and the network, the AllowNetworkingAccess tag must be set to "all".
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[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 250
[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [24] CWE ID 269
[7] Standards Mapping - Common Weakness Enumeration Top 25 2020 [22] CWE ID 269
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [22] CWE ID 269
[9] Standards Mapping - FIPS200 CM
[10] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[13] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[14] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[15] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[18] Standards Mapping - OWASP Application Security Verification Standard 4.0 10.2.2 Malicious Code Search (L2 L3)
[19] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[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 5.4 - Authentication and Access Control
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[26] 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
[27] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.dynamic.actionscript.flash_bad_practices_insecure_embedded_swf_settings
Abstract
Failure to adhere to a safe stage size might allow an attacker to mask critical browser messages that pertain to user privacy.
Explanation
The stage size set in this Flash application must meet the minimum stage requirements as defined by Adobe. Flash security best practices dictate that all Flash objects have a minimum stage of 215 pixels wide and at least 138 pixels high so that Flash Player messages from shared objects, microphone, camera, and other components can be displayed fully to the user.
To protect against clickjacking and spoofing attacks, Flash Player requires the area of the stage that displays the dialog box be visible with the default window mode set.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[8] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[9] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[10] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
desc.dynamic.actionscript.flash_bad_practices_stage_size_too_small
Abstract
Enabling remote debugging of Flash applications can expose sensitive functionality and lead to a severe compromise of the application.
Explanation
The use of ENABLEDEBUGGER and ENABLEDEBUGGER2 enables support for remote debugging and also contains a poorly salted MD5 password hash. The tag does not offer any security guarantees and can be easily circumvented by using any hex editor tool. Not only is the remote debugging protection easily bypassed, the password the developer used to secure the file is easily recoverable. Flash uses a 16-bit salt added to the password and applies the MD5 hash algorithm to it. This is a weak salt and the password can be recovered using password cracking programs.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[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 215
[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[7] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[9] Standards Mapping - FIPS200 CM
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[13] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[14] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[15] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[18] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 14.3.2 Unintended Security Disclosure Requirements (L1 L2 L3)
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[22] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13), Application Misconfiguration (WASC-15)
[23] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dynamic.actionscript.flash_misconfiguration_enabledebugger_tag
Abstract
The program defines an overly permissive cross-domain policy.
Explanation
By default, Flash applications are subject to the Same Origin Policy which ensures that two SWF applications can access each other's data only if they come from the same domain. Adobe Flash allows developers to alter the policy either programmatically or via appropriate settings in the crossdomain.xml configuration file. However, caution should be taken when changing the settings because an overly permissive cross-domain policy will allow a malicious application to communicate with the victim application in an inappropriate way, leading to spoofing, data theft, relay, and other attacks.

Example 1: The following excerpt is an example of using a wildcard to programmatically specify to which domains the application is allowed to communicate.


flash.system.Security.allowDomain("*");


Using the * as the argument to allowDomain() indicates that the application's data is accessible to other SWF applications from any domain.
References
[1] Peleus Uhley Creating more secure SWF web applications
[2] Matt Wood and Prajakta Jagdale Auditing Adobe Flash through Static Analysis
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 942
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [24] CWE ID 863
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[14] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[15] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[17] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.4.6 HTTP Security Headers Requirements (L1 L2 L3), 14.5.3 Validate HTTP Request Header Requirements (L1 L2 L3)
[18] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[27] 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
[28] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[42] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.actionscript.flash_misconfiguration_overly_permissive_cross_domain_policy
Abstract
The program defines an overly permissive custom headers policy.
Explanation
By default, Flash applications are subject to the Same Origin Policy which ensures that two SWF applications can access each other's data only if they come from the same domain. Adobe Flash allows developers to alter the policy either programmatically or via appropriate settings in the crossdomain.xml configuration file. Starting with Flash Player 9,0,124,0, Adobe also introduced the capability to define which custom headers Flash Player can send across domains. However, caution should be taken when defining these settings because an overly permissive custom headers policy, when applied together with the overly permissive cross-domain policy, will allow a malicious application to send headers of their choosing to the target application, potentially leading to a variety of attacks or causing errors in the execution of the application that does not know how to handle received headers.

Example 1: The following configuration shows the use of a wildcard to specify which headers Flash Player can send across domains.


<cross-domain-policy>
<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>


Using the * as the value of the headers attribute indicates that any header will be sent across domains.
References
[1] Peleus Uhley Creating more secure SWF web applications
[2] Matt Wood and Prajakta Jagdale Auditing Adobe Flash through Static Analysis
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[13] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[14] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[15] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[24] 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
[25] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.config.actionscript.flash_misconfiguration_overly_permissive_custom_headers_policy
Abstract
The program uses unvalidated user input to bypass intended cross-domain policy restrictions.
Explanation
By default, Flash applications are subject to the Same Origin Policy which ensures that two SWF applications can access each other's data only if they come from the same domain. Adobe Flash allows developers to alter the policy either programmatically or via appropriate settings in the crossdomain.xml configuration file. However, caution should be taken when deciding who can influence the settings because an overly permissive cross-domain policy will allow a malicious application to communicate with the victim application in an inappropriate way, leading to spoofing, data theft, relay, and other attacks. Policy restrictions bypass vulnerabilities occur when:

1. Data enters an application from an untrusted source.

2. The data is used to load or modify cross-domain policy settings.
Example 1: The following code uses the value of one of the parameters to the loaded SWF file as the URL to load the cross-domain policy file from.


...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var url:String = String(params["url"]);
flash.system.Security.loadPolicyFile(url);
...
Example 2: The following code uses the value of one of the parameters to the loaded SWF file to define the list of trusted domains.


...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var domain:String = String(params["domain"]);
flash.system.Security.allowDomain(domain);
...
References
[1] Peleus Uhley Creating more secure SWF web applications
[2] Matt Wood and Prajakta Jagdale Auditing Adobe Flash through Static Analysis
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[14] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[21] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[23] 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
[24] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.actionscript.flash_misconfiguration_policy_restrictions_bypass
Abstract
Enabling access to the source code of production Flash applications might lead to unintended disclosure of sensitive information.
Explanation
As a convenient debugging option, certain Flex authoring tools allow developers to export Flex projects with the source code files for the project. Failure to disable this access for production files could severely compromise the security of the application. It allows any end user to view the source of the Flex application by right-clicking the running SWF inside the browser and selecting view source. This results in a source disclosure vulnerability. It is recommended that this feature be turned off to avoid unintended access to the source code.

Source code often contains database usernames, passwords and connection strings, and locations of sensitive files. It also reveals the detailed mechanics and design of the application's logic, which can be used to develop other attacks.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 540
[6] Standards Mapping - Common Weakness Enumeration Top 25 2019 [4] CWE ID 200
[7] Standards Mapping - Common Weakness Enumeration Top 25 2020 [7] CWE ID 200
[8] Standards Mapping - Common Weakness Enumeration Top 25 2021 [20] CWE ID 200
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002367, CCI-003109
[10] Standards Mapping - FIPS200 CM
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SA-4 Acquisition Process (P1), SC-18 Mobile Code (P2)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SA-4 Acquisition Process, SC-18 Mobile Code
[14] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[15] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[16] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[19] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 8.3.4 Sensitive Private Data (L1 L2 L3), 12.5.1 File Download Requirements (L1 L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[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.1 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.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 - Security Technical Implementation Guide Version 3.1 APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3620 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003110 CAT I, APSC-DV-003270 CAT II, APSC-DV-003280 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.dynamic.actionscript.flash_misconfiguration_source_code_disclosure
Abstract
The program allows HTTP and HTTPS SWF applications to communicate.
Explanation
Starting with Flash Player 7, SWF applications loaded over HTTP are not allowed to access data of SWF applications loaded over HTTPS by default. Adobe Flash allows developers to alter this restriction either programmatically or via appropriate settings in the crossdomain.xml configuration file. However, caution should be taken when defining these settings because HTTP loaded SWF applications are subject to man-in-the-middle attacks, and thus should not be trusted.

Example: The following code calls allowInsecureDomain(), which turns off the restriction that prevents HTTP loaded SWF applications from accessing the data of HTTPS loaded SWF applications.


flash.system.Security.allowInsecureDomain("*");
References
[1] Peleus Uhley Creating more secure SWF web applications
[2] Matt Wood and Prajakta Jagdale Auditing Adobe Flash through Static Analysis
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001368, CCI-001414
[9] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-4 Information Flow Enforcement (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-4 Information Flow Enforcement
[12] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[13] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[14] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[15] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.4, Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.4, Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.4, Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.4, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[22] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control, Control Objective 6.2 - Sensitive Data Protection
[23] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control, Control Objective 6.2 - Sensitive Data Protection
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective 6.2 - Sensitive Data Protection, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.4.1 - Web Software Communications
[25] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 862
[26] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000480 CAT II, APSC-DV-000490 CAT II
[40] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15)
desc.semantic.actionscript.flash_misconfiguration_unauthorized_data_access
Abstract
Use of deprecated and vulnerable technology can enable attackers to compromise the target by exploiting known vulnerabilities against the detected server.
Explanation
Adobe Flash has been associated with multiple vulnerabilities since its inception. Many of which can lead to Remote Code Execution and Cross-Site Scripting attacks that can compromise user and/or system data and privacy.

Adobe has deprecated Flash with an end-of-life set to the end of 2020. Many browsers have already disabled Adobe Flash support by default, for example, starting in Chrome 76 and Firefox 69. Furthermore, starting in December 2020, Chrome, Firefox, and Microsoft Edge will completely eliminate support for Flash.
Using a deprecated, possibly vulnerable version of the player to execute an application introduces unnecessary risk. Consider updating your application to replace Adobe Flash with safer, alternative technologies that provide similar functionality such as HTML5, WebGL, and WebAssembly. Use of safe alternative technologies is critical to protect users from known player vulnerabilities including Cross-Site Scripting, and Remote Code Execution (on the client machine).
References
[1] Flash and The Future of Interactive Content
[2] CVE Details Mitre
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 937
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code
[12] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[13] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[14] Standards Mapping - OWASP Top 10 2021 A06 Vulnerable and Outdated Components
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.2
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.3.3
[20] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-003300 CAT II
desc.dynamic.actionscript.flash_misconfiguration_vulnerable_flash_engine
Abstract
Debugging information helps attackers learn about the system and plan a form of attack.
Explanation
If you are using Blaze DS to perform logging of any unexpected events, the services-config.xml descriptor file specifies a "Logging" XML element to describe various aspects of logging. It looks like the following:

Example:

<logging>
<target class="flex.messaging.log.ConsoleTarget" level="Debug">
<properties>
<prefix>[BlazeDS]</prefix>
<includeDate>false</includeDate>
<includeTime>false</includeTime>
<includeLevel>false</includeLevel>
<includeCategory>false</includeCategory>
</properties>
<filters>
<pattern>Endpoint.*</pattern>
<pattern>Service.*</pattern>
<pattern>Configuration</pattern>
</filters>
</target>
</logging>


This target tag takes an optional attribute called level, which indicates the log level. If the debug level is set to too detailed a level, your application may write sensitive data to the log file.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[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 complete
[6] Standards Mapping - Common Weakness Enumeration CWE ID 11
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001312, CCI-001314, CCI-002420, CCI-003272
[8] Standards Mapping - FIPS200 CM
[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SA-15 Development Process and Standards and Tools (P2), SC-8 Transmission Confidentiality and Integrity (P1), SI-11 Error Handling (P2)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SA-15 Development Process and Standards and Tools, SC-8 Transmission Confidentiality and Integrity, SI-11 Error Handling
[12] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[13] Standards Mapping - OWASP Top 10 2007 A6 Information Leakage and Improper Error Handling
[14] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[15] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[16] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[17] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[18] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[19] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.1.3 Build (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.10
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.5
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.5
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.5
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.5
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.5
[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 3.6 - Sensitive Data Retention
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.6 - Sensitive Data Retention
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.6 - Sensitive Data Retention
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3120 CAT II, APP3620 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3120 CAT II, APP3620 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3120 CAT II, APP3620 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3120 CAT II, APP3620 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3120 CAT II, APP3620 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3120 CAT II, APP3620 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3120 CAT II, APP3620 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002480 CAT II, APSC-DV-002570 CAT II, APSC-DV-002580 CAT II, APSC-DV-003235 CAT II
[53] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.config.java.flex_misconfiguration_debug_information
Abstract
Concatenating unvalidated input into a URL can allow an attacker to override the value of a request parameter. Attacker may be able to override existing parameter values, inject a new parameter or exploit variables out of a direct reach.
Explanation
HTTP Parameter Pollution (HPP) attacks consist of injecting encoded query string delimiters into other existing parameters. If a web application does not properly sanitize the user input, a malicious user may compromise the logic of the application to perform either client-side or server-side attacks. By submitting additional parameters to a web application, and if these parameters have the same name as an existing parameter, the web application may react in one of the following ways:

It may only take the data from the first parameter
It may take the data from the last parameter
It may take the data from all parameters and concatenate them together


For example:
- ASP.NET/IIS uses all occurrences of the parameters
- Apache Tomcat uses only the first occurrence and ignores others
- mod_perl/Apache converts the value into an array of values

Example 1: Depending on the application server and the logic of the application itself, the following request might cause confusion to the authentication system and allow an attacker to impersonate another user.
http://www.server.com/login.aspx?name=alice&name=hacker

Example 2: The following code uses input from an HTTP request to render two hyperlinks.

...
String lang = Request.Form["lang"];
WebClient client = new WebClient();
client.BaseAddress = url;
NameValueCollection myQueryStringCollection = new NameValueCollection();
myQueryStringCollection.Add("q", lang);
client.QueryString = myQueryStringCollection;
Stream data = client.OpenRead(url);
...


URL: http://www.host.com/election.aspx?poll_id=4567
Link1: <a href="http://www.host.com/vote.aspx?poll_id=4567&lang=en">English<a>
Link2: <a href="http://www.host.com/vote.aspx?poll_id=4567&lang=es">Spanish<a>

The programmer has not considered the possibility that an attacker could provide a lang such as en&poll_id=1, and then the attacker may be able to change the poll_id at will.
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 235
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[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 4.2 - Critical Asset Protection
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.dotnet.http_parameter_pollution
Abstract
Concatenating unvalidated input into a URL can allow an attacker to override the value of a request parameter. Attacker may be able to override existing parameter values, inject a new parameter or exploit variables out of a direct reach.
Explanation
HTTP Parameter Pollution (HPP) attacks consist of injecting encoded query string delimiters into other existing parameters. If a web application does not properly sanitize the user input, a malicious user may compromise the logic of the application to perform either client-side or server-side attacks. By submitting additional parameters to a web application, and if these parameters have the same name as an existing parameter, the web application may react in one of the following ways:

It may only take the data from the first parameter
It may take the data from the last parameter
It may take the data from all parameters and concatenate them together


For example:
- ASP.NET/IIS uses all occurrences of the parameters
- Apache Tomcat uses only the first occurrence and ignores others
- mod_perl/Apache converts the value into an array of values

Example 1: Depending on the application server and the logic of the application itself, the following request might cause confusion to the authentication system and allow an attacker to impersonate another user.
http://www.example.com/login.php?name=alice&name=hacker

Example 2: The following code uses input from an HTTP request to render two hyperlinks.

...
String lang = request.getParameter("lang");
GetMethod get = new GetMethod("http://www.example.com");
get.setQueryString("lang=" + lang + "&poll_id=" + poll_id);
get.execute();
...


URL: http://www.example.com?poll_id=4567
Link1: <a href="http://www.example.com/vote.php?lang=en&poll_id=4567">English<a>
Link2: <a href="http://www.example.com/vote.php?lang=es&poll_id=4567">Spanish<a>

The programmer has not considered the possibility that an attacker could provide a lang such as en&poll_id=1, and then the attacker will be able to change the poll_id at will.
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 235
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[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 4.2 - Critical Asset Protection
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.http_parameter_pollution
Abstract
Concatenating unvalidated input into a URL can allow an attacker to override the value of a request parameter. Attacker may be able to override existing parameter values, inject a new parameter or exploit variables out of a direct reach.
Explanation
HTTP Parameter Pollution (HPP) attacks consist of injecting encoded query string delimiters into other existing parameters. If a web application does not properly sanitize the user input, a malicious user may compromise the logic of the application to perform either client-side or server-side attacks. By submitting additional parameters to a web application, and if these parameters have the same name as an existing parameter, the web application may react in one of the following ways:

It may only take the data from the first parameter
It may take the data from the last parameter
It may take the data from all parameters and concatenate them together


For example:
- ASP.NET/IIS uses all occurrences of the parameters
- Apache Tomcat uses only the first occurrence and ignores others
- mod_perl/Apache converts the value into an array of values

Example 1: Depending on the application server and the logic of the application itself, the following request might cause confusion to the authentication system and allow an attacker to impersonate another user.
http://www.server.com/login.php?name=alice&name=hacker

Example 2: The following code uses input from an HTTP request to render two hyperlinks.


<%
...
$id = $_GET["id"];
header("Location: http://www.host.com/election.php?poll_id=" . $id);
...
%>


URL: http://www.host.com/election.php?poll_id=4567
Link1: <a href="vote.php?poll_id=4567&candidate=white">Vote for Mr. White<a>
Link2: <a href="vote.php?poll_id=4567&candidate=green">Vote for Mrs. Green<a>

The programmer has not considered the possibility that an attacker could provide a poll_id such as "4567&candidate=green", and then the resulting page will contain the following injected links and hence Mrs. Green will always be voted on an application server which picks the first parameter.
<a href="vote.php?poll_id=4567&candidate=green&candidate=white">Vote for Mr. White<a>
<a href="vote.php?poll_id=4567&candidate=green&candidate=green">Vote for Mrs. Green<a>
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 235
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[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 4.2 - Critical Asset Protection
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.php.http_parameter_pollution
Abstract
Concatenating unvalidated input into a URL can allow an attacker to override the value of a request parameter. Attacker may be able to override existing parameter values, inject a new parameter or exploit variables out of a direct reach.
Explanation
HTTP Parameter Pollution (HPP) attacks consist of injecting encoded query string delimiters into other existing parameters. If a web application does not properly sanitize the user input, a malicious user may compromise the logic of the application to perform either client-side or server-side attacks. By submitting additional parameters to a web application, and if these parameters have the same name as an existing parameter, the web application may react in one of the following ways:

It may only take the data from the first parameter.
It may take the data from the last parameter.
It may take the data from all parameters and concatenate them together.


For example:
- ASP.NET/IIS uses all occurrences of the parameters
- Apache Tomcat uses only the first occurrence and ignores others
- mod_perl/Apache converts the value into an array of values

Example 1: Depending on the application server and the logic of the application itself, the following request might cause confusion to the authentication system and allow an attacker to impersonate another user.
http://www.server.com/login.php?name=alice&name=hacker

As this shows, the attacker already has name=alice specified, but they've added an additional name=alice&, and if this is being used on a server that takes the first occurrence, then this may impersonate alice in order to get further information regarding her account.
References
[1] HTTP Parameter Pollution Luca Carettoni, Independent Researcher & Stefano Di Paola, MindedSecurity
[2] HTTP Parameter Pollution Vulnerabilities in Web Applications Marco `embyte’ Balduzzi
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - Common Weakness Enumeration CWE ID 235
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2010 A1 Injection
[16] Standards Mapping - OWASP Top 10 2013 A1 Injection
[17] Standards Mapping - OWASP Top 10 2017 A1 Injection
[18] Standards Mapping - OWASP Top 10 2021 A03 Injection
[19] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.1 Input Validation Requirements (L1 L2 L3), 8.1.3 General Data Protection (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[22] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[23] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[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 4.2 - Critical Asset Protection
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.ruby.http_parameter_pollution
Abstract
The application allows third party keyboard extensions to be installed.
Explanation
Keyboard extensions are allowed to read every single keystroke that a user enters. Third-party keyboards are normally used to ease the text input or to add additional emojis and they may log what the user enters or even send it to a remote server for processing. Malicious keyboards can also be distributed to act as a keylogger and read every key entered by the user in order to steal sensitive data such as credentials or credit card numbers.
References
[1] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[2] UIApplicationDelegate Apple
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 522, CWE ID 829
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [18] CWE ID 522
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [21] CWE ID 522
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[13] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.3 Service Authentication Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 5.3.9 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 12.3.6 File Execution Requirements (L2 L3), 14.2.4 Dependency (L2 L3)
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-3
desc.structural.objc.input_interception_keyboard_extensions_allowed
Abstract
The application allows third party keyboard extensions to be installed.
Explanation
Keyboard extensions are allowed to read every single keystroke that a user enters. Third-party keyboards are normally used to ease the text input or to add additional emojis and they may log what the user enters or even send it to a remote server for processing. Malicious keyboards can also be distributed to act as a keylogger and read every key entered by the user in order to steal sensitive data such as credentials or credit card numbers.
References
[1] UIApplicationDelegate Apple
[2] David Thiel iOS Application Security: The Definitive Guide for Hackers and Developers No Starch Press
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2.0
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 522, CWE ID 829
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [18] CWE ID 522
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [21] CWE ID 522
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287
[13] Standards Mapping - OWASP Top 10 2021 A04 Insecure Design
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.3 Service Authentication Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 5.3.9 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 12.3.6 File Execution Requirements (L2 L3), 14.2.4 Dependency (L2 L3)
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-3
desc.structural.swift.input_interception_keyboard_extensions_allowed
Abstract
Failure to detect and block automated attacks can enable an attacker to conduct brute force attacks or trigger denial of service conditions.
Explanation
All web forms in the application must be protected against automated submissions. An attacker can automatically submit fill and submit registration forms to create fake accounts or overwhelm the database. Contact and messaging forms that do not prevent automated form submissions can be used to spam the application administrators or users. Automated password cracking programs can target login forms with ineffective anti-automation mechanisms. Programmers must always assume that all user interfaces will be abused by attackers in order to find weaknesses.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1.0
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[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 799
[6] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.2.1 General Authenticator Requirements (L1 L2 L3)
[7] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Anti-automation (WASC-21)
desc.dynamic.xtended_preview.insufficient_anti_automation
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key because it significantly reduces the protection afforded by a good encryption algorithm, and it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following uses an empty encryption key:


...
encryptionKey = "".
...


Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.abap.key_management_empty_encryption_key
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key because it significantly reduces the protection afforded by a good encryption algorithm, and it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using an empty encryption key:


...
var encryptionKey:String = "";
var key:ByteArray = Hex.toArray(Hex.fromString(encryptionKey));
...
var aes.ICipher = Crypto.getCipher("aes-cbc", key, padding);
...


Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.actionscript.key_management_empty_encryption_key
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key. Not only does using an empty encryption key significantly reduce the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example: The following code uses an empty encryption key:


...
char encryptionKey[] = "";
...


Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the program ships, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.
References
[1] Encrypting Your App's Files Apple
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 321
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[13] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[15] Standards Mapping - FIPS200 IA
[16] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[25] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[26] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[27] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[40] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.cpp.key_management_empty_encryption_key
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key because it significantly reduces the protection afforded by a good encryption algorithm, and it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using an empty encryption key:


...
<cfset encryptionKey = "" />
<cfset encryptedMsg = encrypt(msg, encryptionKey, 'AES', 'Hex') />
...


Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.cfml.key_management_empty_encryption_key
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key because it significantly reduces the protection afforded by a good encryption algorithm, and it also makes fixing the problem extremely difficult. After the offending code is in production, changing the empty encryption key requires a software patch. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using an empty encryption key:


...
key := []byte("");
block, err := aes.NewCipher(key)
...


Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, changing the empty encryption key requires a software patch, they could extract evidence of the use of an empty encryption key.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.golang.key_management_empty_encryption_key
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key because it significantly reduces the protection afforded by a good encryption algorithm, and it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using an empty encryption key:


...
private static String encryptionKey = "";
byte[] keyBytes = encryptionKey.getBytes();
SecretKeySpec key = new SecretKeySpec(keyBytes, "AES");
Cipher encryptCipher = Cipher.getInstance("AES");
encryptCipher.init(Cipher.ENCRYPT_MODE, key);
...


Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.java.key_management_empty_encryption_key
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key because it significantly reduces the protection afforded by a good encryption algorithm, and it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using an empty encryption key:


...
var crypto = require('crypto');
var encryptionKey = "";
var algorithm = 'aes-256-ctr';
var cipher = crypto.createCipher(algorithm, encryptionKey);
...


Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.javascript.key_management_empty_encryption_key
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key. Not only does using an empty encryption key significantly reduce the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using an empty encryption key:


...
CCCrypt(kCCEncrypt,
kCCAlgorithmAES,
kCCOptionPKCS7Padding,
"",
0,
iv,
plaintext,
sizeof(plaintext),
ciphertext,
sizeof(ciphertext),
&numBytesEncrypted);
...


Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.
References
[1] Encrypting Your App's Files Apple
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 321
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[13] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[15] Standards Mapping - FIPS200 IA
[16] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[25] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[26] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[27] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[40] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.objc.key_management_empty_encryption_key
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key. Not only does using an empty encryption key significantly reduce the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example: The following code initializes an encryption key variable to an empty string.

...
$encryption_key = '';

$filter = new Zend_Filter_Encrypt($encryption_key);

$filter->setVector('myIV');

$encrypted = $filter->filter('text_to_be_encrypted');
print $encrypted;
...

Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the program ships, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.
References
[1] Windows Data Protection Microsoft
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 321
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[13] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[15] Standards Mapping - FIPS200 IA
[16] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[25] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[26] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[27] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[40] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.php.key_management_empty_encryption_key
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key because it significantly reduces the protection afforded by a good encryption algorithm, and it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.



Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.sql.key_management_empty_encryption_key
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key. Not only does using an empty encryption key significantly reduce the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example: The following code initializes an encryption key variable to an empty string.

...
from Crypto.Ciphers import AES
cipher = AES.new("", AES.MODE_CFB, iv)
msg = iv + cipher.encrypt(b'Attack at dawn')
...


Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the program ships, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.python.key_management_empty_encryption_key
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key. Not only does using an empty encryption key significantly reduce the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a password-based key derivation function with a key length of zero, which produces an empty encryption key:


require 'openssl'
...
dk = OpenSSL::PKCS5::pbkdf2_hmac_sha1(password, salt, 100000, 0) # returns an empty string
...


Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the program ships, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.ruby.key_management_empty_encryption_key
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key. Not only does using an empty encryption key significantly reduce the protection afforded by a good encryption algorithm, but it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using an empty encryption key:


...
CCCrypt(UInt32(kCCEncrypt),
UInt32(kCCAlgorithmAES128),
UInt32(kCCOptionPKCS7Padding),
"",
0,
iv,
plaintext,
plaintext.length,
ciphertext.mutableBytes,
ciphertext.length,
&numBytesEncrypted)
...


Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the program ships, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.
References
[1] Encrypting Your App's Files Apple
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 321
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[13] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[15] Standards Mapping - FIPS200 IA
[16] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[25] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[26] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[27] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[40] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[41] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.swift.key_management_empty_encryption_key
Abstract
Empty encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty encryption key because it significantly reduces the protection afforded by a good encryption algorithm, and it also makes fixing the problem extremely difficult. After the offending code is in production, the empty encryption key cannot be changed without patching the software. If an account that is protected by the empty encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code performs AES encryption using an empty encryption key:


...
Dim encryptionKey As String
Set encryptionKey = ""
Dim AES As New System.Security.Cryptography.RijndaelManaged
On Error GoTo ErrorHandler
AES.Key = System.Text.Encoding.ASCII.GetBytes(encryptionKey)
...
Exit Sub
...


Not only will anyone who has access to the code be able to determine that it uses an empty encryption key, but anyone with even basic cracking techniques is much more likely to successfully decrypt any encrypted data. After the application has shipped, a software patch is required to change the empty encryption key. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty encryption key.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450, CCI-002478
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1), SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1), SC-28 Protection of Information at Rest (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-28 Protection of Information at Rest
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II, APSC-DV-003100 CAT II, APSC-DV-003310 CAT II
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.vb.key_management_empty_encryption_key
Abstract
Empty HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.
Example 1: The following code uses an empty key to compute the HMAC:

...
DATA: lo_hmac TYPE Ref To cl_abap_hmac,
Input_string type string.

CALL METHOD cl_abap_hmac=>get_instance
EXPORTING
if_algorithm = 'SHA3'
if_key = space
RECEIVING
ro_object = lo_hmac.

" update HMAC with input
lo_hmac->update( if_data = input_string ).

" finalise hmac
lo_digest->final( ).

...


The code shown in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 321
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[16] Standards Mapping - FIPS200 IA
[17] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[20] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[21] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[23] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[25] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[27] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[28] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[29] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[41] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.abap.key_management_empty_hmac_key
Abstract
Empty HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.
Example 1: The following code uses an empty key to compute the HMAC:

...
using (HMAC hmac = HMAC.Create("HMACSHA512"))
{
string hmacKey = "";
byte[] keyBytes = Encoding.ASCII.GetBytes(hmacKey);
hmac.Key = keyBytes;
...
}
...


The code in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 321
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[16] Standards Mapping - FIPS200 IA
[17] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[20] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[21] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[23] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[25] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[27] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[28] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[29] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[41] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.dotnet.key_management_empty_hmac_key
Abstract
Empty HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
Never use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.

Example 1: The following code uses an empty key to compute the HMAC:


import "crypto/hmac"
...
hmac.New(md5.New, []byte(""))
...


The code in Example 1 might run successfully, but anyone who has access to it can determine that it uses an empty HMAC key. After the program ships, there is no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 321
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[16] Standards Mapping - FIPS200 IA
[17] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[20] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[21] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[23] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[25] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[27] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[28] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[29] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[41] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.golang.key_management_empty_hmac_key
Abstract
Empty HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.
Example 1: The following code uses an empty key to compute the HMAC:

...
private static String hmacKey = "";
byte[] keyBytes = hmacKey.getBytes();
...
SecretKeySpec key = new SecretKeySpec(keyBytes, "SHA1");
Mac hmac = Mac.getInstance("HmacSHA1");
hmac.init(key);
...


The code in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 321
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[16] Standards Mapping - FIPS200 IA
[17] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[20] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[21] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[23] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[25] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[27] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[28] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[29] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[41] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.java.key_management_empty_hmac_key
Abstract
Empty HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.
Example 1: The following code uses an empty HMAC key to generate the HMAC hash:

...
let hmacKey = "";
let hmac = crypto.createHmac("SHA256", hmacKey);
hmac.update(data);
...


The code in Example 1 might run successfully, but anyone with access to it might figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 321
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[16] Standards Mapping - FIPS200 IA
[17] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[20] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[21] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[23] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[25] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[27] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[28] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[29] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[41] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.javascript.key_management_empty_hmac_key
Abstract
Empty HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.

Example 1: The following code uses an empty key to compute the HMAC:


...
CCHmac(kCCHmacAlgSHA256, "", 0, plaintext, plaintextLen, &output);
...


The code in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 321
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[16] Standards Mapping - FIPS200 IA
[17] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[20] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[21] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[23] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[25] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[27] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[28] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[29] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[41] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.objc.key_management_empty_hmac_key
Abstract
Empty HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.

Example 1: The following code uses an empty key to compute the HMAC:


import hmac
...
mac = hmac.new("", plaintext).hexdigest()
...


The code in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 321
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[16] Standards Mapping - FIPS200 IA
[17] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[20] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[21] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[23] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[25] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[27] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[28] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[29] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[41] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.python.key_management_empty_hmac_key
Abstract
Empty HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.

Example 1: The following code uses an empty key to compute the HMAC:

...
digest = OpenSSL::HMAC.digest('sha256', '', data)
...


The code in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 321
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[16] Standards Mapping - FIPS200 IA
[17] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[20] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[21] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[23] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[25] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[27] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[28] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[29] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[41] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.ruby.key_management_empty_hmac_key
Abstract
Empty HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.

Example 1: The following code uses an empty key to compute the HMAC:


...
CCHmac(UInt32(kCCHmacAlgSHA256), "", 0, plaintext, plaintextLen, &output)
...


The code in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 321
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[16] Standards Mapping - FIPS200 IA
[17] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[20] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[21] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[23] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[25] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[27] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[28] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[29] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[41] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.swift.key_management_empty_hmac_key
Abstract
Using a key generated by a password-based key derivation function that was passed an empty value for its password argument might compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:


...
Rfc2898DeriveBytes rdb = new Rfc2898DeriveBytes("", salt,100000);
...


Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on an empty password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.dotnet.key_management_empty_pbe_password
Abstract
An empty password is used to generate a key from a password-based key derivation function (PBKDF). Providing an empty password to a PBKDF compromises system security in a way that is not easily remedied.
Explanation
It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:


...
var encryptor = new StrongPasswordEncryptor();
var encryptedPassword = encryptor.encryptPassword("");
...


Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on an empty password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.java.key_management_empty_pbe_password
Abstract
Providing an empty password to a PBKDF compromises system security in a way that is not easily to remedy.
Explanation
It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key is based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:


const pbkdfPassword = "";
crypto.pbkdf2(
pbkdfPassword,
salt,
numIterations,
keyLen,
hashAlg,
function (err, derivedKey) { ... }
)


Not only can anyone with access to the code determine that it generates one or more cryptographic keys based on an empty password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.javascript.key_management_empty_pbe_password
Abstract
An empty password is used to generate a key from a password-based key derivation function (PBKDF). Providing an empty password to a PBKDF compromises system security in a way that is not easily remedied.
Explanation
It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:


...
CCKeyDerivationPBKDF(kCCPBKDF2,
"",
0,
salt,
saltLen
kCCPRFHmacAlgSHA256,
100000,
derivedKey,
derivedKeyLen);
...


Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on an empty password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.

Example 2: Some lower-level APIs may require passing the length of certain arguments as well as the argument values themselves, such that a function can read the argument's value as a number of consecutive bytes beginning at the argument's location in memory. The following code passes zero as the password length argument to a cryptographic PBKDF:


...
CCKeyDerivationPBKDF(kCCPBKDF2,
password,
0,
salt,
saltLen
kCCPRFHmacAlgSHA256,
100000,
derivedKey,
derivedKeyLen);
...


In this scenario, even if password contains a strong, appropriately managed password value, passing its length as zero will result in an empty, null, or otherwise unexpected weak password value.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.objc.key_management_empty_pbe_password
Abstract
An empty password is used to generate a key from a password-based key derivation function (PBKDF). Providing an empty password to a PBKDF compromises system security in a way that is not easily remedied.
Explanation
It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:


...
$zip = new ZipArchive();
$zip->open("test.zip", ZipArchive::CREATE);
$zip->setEncryptionIndex(0, ZipArchive::EM_AES_256, "");
...


Anyone with access to the code can determine that it generates one or more cryptographic keys based on an empty password argument. Additionally, anyone with even basic cracking techniques might successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.php.key_management_empty_pbe_password
Abstract
An empty password is used to generate a key from a password-based key derivation function (PBKDF). Providing an empty password to a PBKDF compromises system security in a way that is not easily remedied.
Explanation
It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:


from hashlib import pbkdf2_hmac
...
dk = pbkdf2_hmac('sha256', '', salt, 100000)
...


Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on an empty password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.python.key_management_empty_pbe_password
Abstract
An empty password is used to generate a key from a password-based key derivation function (PBKDF). Providing an empty password to a PBKDF compromises system security in a way that is not easily remedied.
Explanation
It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:


...
key = OpenSSL::PKCS5::pbkdf2_hmac('', salt, 100000, 256, 'SHA256')
...


Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on an empty password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.ruby.key_management_empty_pbe_password
Abstract
An empty password is used to generate a key from a password-based key derivation function (PBKDF). Providing an empty password to a PBKDF compromises system security in a way that is not easily remedied.
Explanation
It is never a good idea to pass an empty value as the password argument to a cryptographic password-based key derivation function (PBKDF). In this scenario, the derived key will be based solely on the provided salt (rendering it significantly weaker), and fixing the problem is extremely difficult. After the offending code is in production, the empty password often cannot be changed without patching the software. If an account protected by a derived key based on an empty password is compromised, the owners of the system might be forced to choose between security and availability.

Example 1: The following code passes the empty string as the password argument to a cryptographic PBKDF:


...
CCKeyDerivationPBKDF(CCPBKDFAlgorithm(kCCPBKDF2),
"",
0,
salt,
saltLen,
CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256),
100000,
derivedKey,
derivedKeyLen)
...


Not only will anyone who has access to the code be able to determine that it generates one or more cryptographic keys based on an empty password argument, but anyone with even basic cracking techniques is much more likely to successfully gain access to any resources protected by the offending keys. If an attacker also has access to the salt value used to generate any of the keys based on an empty password, cracking those keys becomes trivial. After the program ships, there is likely no way to change the empty password unless the program is patched. An employee with access to this information can use it to break into the system. Even if attackers only had access to the application's executable, they could extract evidence of the use of an empty password.

Example 2: Some lower-level APIs may require passing the length of certain arguments as well as the argument values themselves, such that a function can read the argument's value as a number of consecutive bytes beginning at the argument's location in memory. The following code passes zero as the password length argument to a cryptographic PBKDF:


...
CCKeyDerivationPBKDF(CCPBKDFAlgorithm(kCCPBKDF2),
password,
0,
salt,
saltLen,
CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256),
100000,
derivedKey,
derivedKeyLen)
...


In this scenario, even if password contains a strong, appropriately managed password value, passing its length as zero will result in an empty, null, or otherwise unexpected weak password value.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.swift.key_management_empty_pbe_password
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:


...
encryptionKey = "lakdsljkalkjlksdfkl".
...


Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[41] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.abap.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:


...
var encryptionKey:String = "lakdsljkalkjlksdfkl";
var key:ByteArray = Hex.toArray(Hex.fromString(encryptionKey));
...
var aes.ICipher = Crypto.getCipher("aes-cbc", key, padding);
...


Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[41] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.actionscript.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
Never hardcode an encryption key because it makes the encryption key visible to all of the project's developers, and makes fixing the problem extremely difficult. Changing the encryption key after the code is in production requires a software patch. If the account that the encryption key protects is compromised, the organization must choose between security and system availability.

Example 1: The following code performs AES encryption using a hardcoded encryption key:


...
Blob encKey = Blob.valueOf('YELLOW_SUBMARINE');
Blob encrypted = Crypto.encrypt('AES128', encKey, iv, input);
...


Anyone with access to the code can see the encryption key. After the application has shipped, there is no way to change the encryption key without a software patch. An employee with access to this information can use it to break into the system. Any attacker with access to the application executable can extract the encryption key value.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[41] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.apex.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:


...
using (SymmetricAlgorithm algorithm = SymmetricAlgorithm.Create("AES"))
{
string encryptionKey = "lakdsljkalkjlksdfkl";
byte[] keyBytes = Encoding.ASCII.GetBytes(encryptionKey);
algorithm.Key = keyBytes;
...
}


Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[41] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.dotnet.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key. Not only does hardcoding an encryption key allow all of the project's developers to view the encryption key, it also makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example: The following code uses a hardcoded encryption key:


...
char encryptionKey[] = "lakdsljkalkjlksdfkl";
...


Anyone with access to the code has access to the encryption key. After the program ships, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers have access to the executable for the application they can disassemble the code, which will contain the value of the encryption key used.
References
[1] Windows Data Protection Microsoft
[2] Encrypting Your App's Files Apple
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 321
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[16] Standards Mapping - FIPS200 IA
[17] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[20] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[21] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[23] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[25] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[27] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[28] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[29] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[41] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[42] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[43] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[44] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[63] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[64] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[65] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.cpp.hardcoded_encryption_key
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:


...
<cfset encryptionKey = "lakdsljkalkjlksdfkl" />
<cfset encryptedMsg = encrypt(msg, encryptionKey, 'AES', 'Hex') />
...


Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[41] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.cfml.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key because all of the project's developers can view the encryption key, and fixing the problem is extremely difficult. After the code is in production, changing the encryption key requires a software patch. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:


...
key := []byte("lakdsljkalkjlksd");
block, err := aes.NewCipher(key)
...


Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.
References
[1] MSC03-J. Never hard code sensitive information CERT
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 321
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[13] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[15] Standards Mapping - FIPS200 IA
[16] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[25] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[26] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[27] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[40] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[41] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[42] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[43] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[63] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[64] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.golang.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:


...
private static final String encryptionKey = "lakdsljkalkjlksdfkl";
byte[] keyBytes = encryptionKey.getBytes();
SecretKeySpec key = new SecretKeySpec(keyBytes, "AES");
Cipher encryptCipher = Cipher.getInstance("AES");
encryptCipher.init(Cipher.ENCRYPT_MODE, key);
...


Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.
References
[1] MSC03-J. Never hard code sensitive information CERT
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 321
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[13] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[15] Standards Mapping - FIPS200 IA
[16] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[25] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[26] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[27] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[40] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[41] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[42] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[43] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[63] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[64] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.java.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:


...
var crypto = require('crypto');
var encryptionKey = "lakdsljkalkjlksdfkl";
var algorithm = 'aes-256-ctr';
var cipher = crypto.createCipher(algorithm, encryptionKey);
...


Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[41] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.javascript.key_management_hardcoded_encryption_key
Abstract
Hardcoded passwords can compromise system security in a way that is difficult to remedy.
Explanation
Never hardcode passwords. Not only does it expose the password to all of the project's developers, it also makes fixing the problem extremely difficult. After the code is in production, a program patch is probably the only way to change the password. If the account the password protects is compromised, the system owners must choose between security and availability.
Example: The following JSON uses a hardcoded password:


...
{
"username":"scott"
"password":"tiger"
}
...


This configuration may be valid, but anyone who has access to the configuration will have access to the password. After the program is released, changing the default user account "scott" with a password of "tiger" is difficult. Anyone with access to this information can use it to break into the system.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[41] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.json.password_management_hardcoded_password
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:


...
NSString encryptionKey = "lakdsljkalkjlksdfkl";
...


Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.
References
[1] Encrypting Your App's Files Apple
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 321
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[13] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[15] Standards Mapping - FIPS200 IA
[16] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[25] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[26] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[27] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[40] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[41] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[42] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[43] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[63] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[64] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.objc.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key. Not only does hardcoding an encryption key allow all of the project's developers to view the encryption key, it also makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account protected by the encryption key is compromised, the owners of the system must choose between security and availability.
Example: The following code uses a hardcoded encryption key to encrypt information:


...
$encryption_key = 'hardcoded_encryption_key';

//$filter = new Zend_Filter_Encrypt('hardcoded_encryption_key');
$filter = new Zend_Filter_Encrypt($encryption_key);

$filter->setVector('myIV');

$encrypted = $filter->filter('text_to_be_encrypted');
print $encrypted;
...


This code will run successfully, but anyone who has access to it will have access to the encryption key. After the program ships, there is likely no way to change the hardcoded encryption key ('hardcoded_encryption_key') unless the program is patched. A devious employee with access to this information can use it to compromise data encrypted by the system.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[41] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.php.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.



Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[41] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.sql.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key. Not only does hardcoding an encryption key allow all of the project's developers to view the encryption key, it also makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account protected by the encryption key is compromised, the owners of the system must choose between security and availability.
Example: The following code uses a hardcoded encryption key to encrypt information:

...
from Crypto.Ciphers import AES
encryption_key = b'_hardcoded__key_'
cipher = AES.new(encryption_key, AES.MODE_CFB, iv)
msg = iv + cipher.encrypt(b'Attack at dawn')
...


This code will run successfully, but anyone who has access to it will have access to the encryption key. After the program ships, there is likely no way to change the hardcoded encryption key _hardcoded__key_ unless the program is patched. A devious employee with access to this information can use it to compromise data encrypted by the system.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[41] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.python.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key. Not only does hardcoding an encryption key allow all of the project's developers to view the encryption key, it also makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account protected by the encryption key is compromised, the owners of the system must choose between security and availability.
Example 1: The following code uses a hardcoded encryption key:


require 'openssl'
...
encryption_key = 'hardcoded_encryption_key'
...
cipher = OpenSSL::Cipher::AES.new(256, 'GCM')
cipher.encrypt
...
cipher.key=encryption_key
...


This code will run successfully, but anyone who has access to it will have access to the encryption key. After the program ships, there is likely no way to change the hardcoded encryption key "hardcoded_encryption_key" unless the program is patched. A devious employee with access to this information can use it to compromise data encrypted by the system.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[41] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.ruby.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key. Not only does hardcoding an encryption key allow all of the project's developers to view the encryption key, it also makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:


...
let encryptionKey = "YELLOW_SUBMARINE"
...
Example 2: The following code performs AES encryption using a hardcoded encryption key:


...
CCCrypt(UInt32(kCCEncrypt),
UInt32(kCCAlgorithmAES128),
UInt32(kCCOptionPKCS7Padding),
"YELLOW_SUBMARINE",
16,
iv,
plaintext,
plaintext.length,
ciphertext.mutableBytes,
ciphertext.length,
&numBytesEncrypted)
...


Anyone with access to the code has access to the encryption key. After the program ships, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application they could extract the encryption key value.
References
[1] Encrypting Your App's Files Apple
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[7] Standards Mapping - CIS Kubernetes Benchmark partial
[8] Standards Mapping - Common Weakness Enumeration CWE ID 321
[9] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[13] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[15] Standards Mapping - FIPS200 IA
[16] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[19] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[20] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[25] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[26] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[27] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[28] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[40] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[41] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[42] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[43] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[63] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[64] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.swift.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
Never hardcode an encryption key because it makes the encryption key visible to all of the project's developers, and makes fixing the problem extremely difficult. Changing the encryption key after the code is in production requires a software patch. If the account that the encryption key protects is compromised, the organization must choose between security and system availability.

Example 1: The following example shows an encryption key inside a .pem file:


...
-----BEGIN RSA PRIVATE KEY-----
MIICXwIBAAKBgQCtVacMo+w+TFOm0p8MlBWvwXtVRpF28V+o0RNPx5x/1TJTlKEl
...
DiJPJY2LNBQ7jS685mb6650JdvH8uQl6oeJ/aUmq63o2zOw=
-----END RSA PRIVATE KEY-----
...


Anyone with access to the code can see the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. Any attacker with access to the application executable can extract the encryption key value.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[41] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.regex.universal.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an encryption key because it allows all of the project's developers to view the encryption key, and makes fixing the problem extremely difficult. After the code is in production, a software patch is required to change the encryption key. If the account that is protected by the encryption key is compromised, the owners of the system must choose between security and availability.

Example 1: The following code uses a hardcoded encryption key:


...
Dim encryptionKey As String
Set encryptionKey = "lakdsljkalkjlksdfkl"
Dim AES As New System.Security.Cryptography.RijndaelManaged
On Error GoTo ErrorHandler
AES.Key = System.Text.Encoding.ASCII.GetBytes(encryptionKey)
...
Exit Sub
...


Anyone with access to the code has access to the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. If attackers had access to the executable for the application, they could extract the encryption key value.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[41] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.vb.key_management_hardcoded_encryption_key
Abstract
Hardcoded encryption keys can compromise security in a way that is not easy to remedy.
Explanation
Never hardcode an encryption key because it makes the encryption key visible to all of the project's developers, and makes fixing the problem extremely difficult. Changing the encryption key after the code is in production requires a software patch. If the account that the encryption key protects is compromised, the organization must choose between security and system availability.

Example 1: The following example shows an encryption key inside the secrets.yml file of a Ruby on Rails configuration:


...
production:
secret_key_base: 0ab25e26286c4fb9f7335947994d83f19861354f19702b7bbb84e85310b287ba3cdc348f1f19c8cdc08a7c6c5ad2c20ad31ecda177d2c74aa2d48ec4a346c40e
...


Anyone with access to the code can see the encryption key. After the application has shipped, there is no way to change the encryption key unless the program is patched. An employee with access to this information can use it to break into the system. Any attacker with access to the application executable can extract the encryption key value.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[41] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.yaml.key_management_hardcoded_encryption_key
Abstract
Hardcoded HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an HMAC key. The cryptographic strength of HMAC depends on the confidentiality of the secret key, which is used for the calculation and verification of the message authentication values. Hardcoding an HMAC key allows anyone with access to the source to view it, and undermines the cryptographic strength of the function.
Example: The following code uses a hardcoded key to compute the HMAC:

...
DATA: lo_hmac TYPE Ref To cl_abap_hmac,
Input_string type string.

CALL METHOD cl_abap_hmac=>get_instance
EXPORTING
if_algorithm = 'SHA3'
if_key = 'secret_key'
RECEIVING
ro_object = lo_hmac.

" update HMAC with input
lo_hmac->update( if_data = input_string ).

" finalise hmac
lo_digest->final( ).

...


This code will run successfully, but anyone who has access to it will have access to the HMAC key. After the program ships, there is likely no way to change the hardcoded HMAC key "secret_key" unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 321
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[16] Standards Mapping - FIPS200 IA
[17] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[20] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[21] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[23] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[25] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[27] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[28] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[29] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[41] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[42] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[43] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[44] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[63] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[64] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[65] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.abap.key_management_hardcoded_hmac_key
Abstract
Hardcoded HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an HMAC key. The cryptographic strength of HMAC depends on the confidentiality of the secret key, which is used for the calculation and verification of the message authentication values. Hardcoding an HMAC key allows anyone with access to the source to view it, and undermines the cryptographic strength of the function.
Example: The following code uses a hardcoded key to compute the HMAC:

...
using (HMAC hmac = HMAC.Create("HMACSHA512"))
{
string hmacKey = "lakdsljkalkjlksdfkl";
byte[] keyBytes = Encoding.ASCII.GetBytes(hmacKey);
hmac.Key = keyBytes;
...
}


This code will run successfully, but anyone who has access to it will have access to the HMAC key. After the program ships, there is likely no way to change the hardcoded HMAC key "hmacKey" unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 321
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[16] Standards Mapping - FIPS200 IA
[17] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[20] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[21] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[23] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[25] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[27] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[28] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[29] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[41] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[42] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[43] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[44] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[63] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[64] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[65] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.dotnet.key_management_hardcoded_hmac_key
Abstract
Hardcoded HMAC keys can compromise system security in a way that is not easy to remedy.
Explanation
Never hardcode an HMAC key. The cryptographic strength of HMAC depends on the confidentiality of the secret key, which is used for the calculation and verification of the message authentication values. Hardcoding an HMAC key allows anyone with access to the source to view it and undermines the cryptographic strength of the function.

Example 1: The following code uses a hardcoded key to compute the HMAC:


import "crypto/hmac"
...
hmac.New(sha256.New, []byte("secret"))
...


This code runs successfully, but anyone who has access to the source has access to the HMAC key. After the program ships, there is no way to change the hardcoded HMAC key "secret" unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 321
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[16] Standards Mapping - FIPS200 IA
[17] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[20] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[21] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[23] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[25] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[27] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[28] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[29] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[41] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[42] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[43] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[44] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[63] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[64] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[65] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.golang.key_management_hardcoded_hmac_key
Abstract
Hardcoded HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an HMAC key. The cryptographic strength of HMAC depends on the confidentiality of the secret key, which is used for the calculation and verification of the message authentication values. Hardcoding an HMAC key allows anyone with access to the source to view it, and undermines the cryptographic strength of the function.
Example: The following code uses a hardcoded key to compute the HMAC:

...
private static String hmacKey = "lakdsljkalkjlksdfkl";
byte[] keyBytes = hmacKey.getBytes();
...
SecretKeySpec key = new SecretKeySpec(keyBytes, "SHA1");
Mac hmac = Mac.getInstance("HmacSHA1");
hmac.init(key);
...


This code will run successfully, but anyone who has access to it will have access to the HMAC key. After the program ships, there is likely no way to change the hardcoded HMAC key "hmacKey" unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] MSC03-J. Never hard code sensitive information CERT
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[9] Standards Mapping - CIS Kubernetes Benchmark partial
[10] Standards Mapping - Common Weakness Enumeration CWE ID 321
[11] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[13] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[14] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[15] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[16] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[17] Standards Mapping - FIPS200 IA
[18] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[19] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[20] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[21] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[22] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[23] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[24] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[25] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[26] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[27] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[28] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[29] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[30] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[41] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[42] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[43] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[44] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[45] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[63] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[64] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[65] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[66] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.semantic.java.key_management_hardcoded_hmac_key
Abstract
Hardcoded HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an HMAC key. The cryptographic strength of HMAC depends on the confidentiality of the secret key, which is used for the calculation and verification of the message authentication values. Hardcoding an HMAC key makes it available to anyone with access to the source, and undermines the cryptographic strength of the function.
Example: The following code uses a hardcoded key to compute the HMAC:

const hmacKey = "a secret";
const hmac = createHmac('sha256', hmacKey);
hmac.update(data);
...


This code runs successfully, but anyone with access to it has access to the HMAC key. After the program ships, there is likely no way to change the hardcoded hmacKey unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[6] Standards Mapping - CIS Kubernetes Benchmark partial
[7] Standards Mapping - Common Weakness Enumeration CWE ID 321
[8] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[9] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[10] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[13] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[14] Standards Mapping - FIPS200 IA
[15] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[16] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[17] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[18] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[19] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[21] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[23] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[24] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[25] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[26] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[27] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[37] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[39] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[40] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[41] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[42] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.javascript.key_management_hardcoded_hmac_key
Abstract
Hardcoded HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an HMAC key. The cryptographic strength of HMAC depends on the confidentiality of the secret key, which is used for the calculation and verification of the message authentication values. Hardcoding an HMAC key allows anyone with access to the source to view it, and undermines the cryptographic strength of the function.

Example: The following code uses a hardcoded key to compute the HMAC:


...
CCHmac(kCCHmacAlgSHA256, "secret", 6, plaintext, plaintextLen, &output);
...


This code will run successfully, but anyone who has access to it will have access to the HMAC key. After the program ships, there is likely no way to change the hardcoded HMAC key "secret" unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 321
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[16] Standards Mapping - FIPS200 IA
[17] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[20] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[21] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[23] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[25] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[27] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[28] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[29] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[41] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[42] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[43] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[44] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[63] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[64] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[65] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.objc.key_management_hardcoded_hmac_key
Abstract
Hardcoded HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an HMAC key. The cryptographic strength of HMAC depends on the confidentiality of the secret key, which is used for the calculation and verification of the message authentication values. Hardcoding an HMAC key allows anyone with access to the source to view it, and undermines the cryptographic strength of the function.

Example 1: The following code uses a hardcoded key to compute the HMAC:


import hmac
...
mac = hmac.new("secret", plaintext).hexdigest()
...


This code will run successfully, but anyone who has access to it will have access to the HMAC key. After the program ships, there is likely no way to change the hardcoded HMAC key "secret" unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 321
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[16] Standards Mapping - FIPS200 IA
[17] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[20] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[21] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[23] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[25] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[27] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[28] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[29] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[41] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[42] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[43] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[44] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[63] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[64] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[65] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.python.key_management_hardcoded_hmac_key
Abstract
Hardcoded HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an HMAC key. The cryptographic strength of HMAC depends on the confidentiality of the secret key, which is used for the calculation and verification of the message authentication values. Hardcoding an HMAC key allows anyone with access to the source to view it, and undermines the cryptographic strength of the function.
Example: The following code uses a hardcoded key to compute the HMAC:

...
digest = OpenSSL::HMAC.digest('sha256', 'secret_key', data)
...


This code will run successfully, but anyone who has access to it will have access to the HMAC key. After the program ships, there is likely no way to change the hardcoded HMAC key "secret_key" unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 321
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[16] Standards Mapping - FIPS200 IA
[17] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[20] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[21] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[23] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[25] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[27] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[28] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[29] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[41] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[42] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[43] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[44] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[63] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[64] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[65] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.ruby.key_management_hardcoded_hmac_key
Abstract
Hardcoded HMAC keys could compromise system security in a way that is not easy to remedy.
Explanation
It is never a good idea to hardcode an HMAC key. The cryptographic strength of HMAC depends on the confidentiality of the secret key, which is used for the calculation and verification of the message authentication values. Hardcoding an HMAC key allows anyone with access to the source to view it, and undermines the cryptographic strength of the function.

Example: The following code uses a hardcoded key to compute the HMAC:


...
CCHmac(UInt32(kCCHmacAlgSHA256), "secret", 6, plaintext, plaintextLen, &output)
...


This code will run successfully, but anyone who has access to it will have access to the HMAC key. After the program ships, there is likely no way to change the hardcoded HMAC key "secret" unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.
References
[1] RFC 2104 - HMAC: Keyed-Hashing for Message Authentication Internet Engineering Task Force (IETF)
[2] New Results on NMAC/HMAC when Instantiated with Popular Hash Functions Journal of Universal Computer Science (J.UCS)
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4.0
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 3.0
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 3
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 321
[10] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[14] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[15] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[16] Standards Mapping - FIPS200 IA
[17] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[18] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1), SC-13 Cryptographic Protection (P1)
[19] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection
[20] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[21] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[22] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[23] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[24] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[25] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[26] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.9.1 Cryptographic Software and Devices Verifier Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 6.4.2 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[27] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[28] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[29] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.7.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6
[38] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[39] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[40] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.2 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[41] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[42] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[43] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[44] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3350 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3350 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3350 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3350 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3350 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3350 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II
[62] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II
[63] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II
[64] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002010 CAT II
[65] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
desc.structural.swift.key_management_hardcoded_hmac_key