146 items found
Weaknesses
Abstract
Cryptographic signature functions that take a key size parameter should not be passed a tainted key size value.
Explanation
Allowing a user-controlled value to determine the key size may enable the attacker to specify an empty key, allowing for the modification of a cryptographic signature that ensures integrity of encrypted data. Even if a non-zero value is required, the attacker could still specify the lowest possible key size value, decreasing the integrity of the encrypted data.

Weak Cryptographic Hash: User-Controlled Key Size issues occur when:

1. Data enters a program through an untrusted source

2. User-controlled data is used as all or part of the key size parameter within a cryptographic signature function

As with many software security vulnerabilities, Weak Cryptographic Hash: User-Controlled Key Size is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application and that data is then used as all or part of the key size value while performing encryption.

Current cryptography guidelines suggest that a key length of at least 2048 bits should be used with the RSA and DSA algorithms. However, continued advancements in computing power and factoring techniques [1] mean that future increases in the recommended key size are inevitable. If user input is even used as a partial key size, it may greatly weaken the security of the signature, and therefore the integrity of the encrypted data.

Example 1: The following code generates a DSA signature key using a user-controlled key size parameter:

...
DSA dsa1 = new DSACryptoServiceProvider(Convert.ToInt32(TextBox1.Text));
...


There are few use cases where users should be able to determine key_len, and even then there should be appropriate protection to verify both that it is a numeric value and that it is within a suitable range of values for a key size. For most use cases, this should be a sufficiently high hardcoded number.
References
[1] J. Cheng 307-digit key crack endangers 1024-bit RSA
[2] Elaine Barker and Allen Roginsky NIST Special Publication 800-131A: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths. NIST
[3] B. Chess and J. West, Secure Programming with Static Analysis. Boston, MA: Addison-Wesley, 2007.
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.5
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[8] Standards Mapping - CIS Kubernetes Benchmark complete
[9] Standards Mapping - Common Weakness Enumeration CWE ID 326
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[11] Standards Mapping - FIPS200 MP
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[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.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.8.3 Single or Multi Factor One Time Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.2.3 Algorithms (L2 L3), 6.2.4 Algorithms (L2 L3), 6.2.5 Algorithms (L2 L3), 6.2.6 Algorithms (L2 L3), 6.2.7 Algorithms (L3), 9.1.2 Communications Security Requirements (L1 L2 L3), 9.1.3 Communications Security Requirements (L1 L2 L3)
[22] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[23] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.6.1, Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.6.1, Requirement 6.3.1.3, Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.6.1, Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.6.1, Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.6.1, Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.6.1, Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.6.1, Requirement 6.5.3
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.6.1, Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[34] 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
[35] 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
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002020 CAT II, APSC-DV-002290 CAT II
desc.dataflow.dotnet.weak_cryptographic_signature_user_controlled_key_size
Abstract
Cryptographic signature functions that take a key size can receive a tainted key size value.
Explanation
By allowing a user-controlled value to determine the key size, an attacker can specify an empty key, which allows modification of a cryptographic signature that ensures integrity of encrypted data. Even if a non-zero value is required, the attacker could still specify the lowest possible key size value, decreasing the integrity of the encrypted data.

Weak Cryptographic Signature: User-Controlled Key Size issues occur when:

1. Data enters a program through an untrusted source.

2. User-controlled data is used as all or part of the key size parameter within a cryptographic signature function.

As with many software security vulnerabilities, Weak Cryptographic Signature: User-Controlled Key Size is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application and that data is then used as all or part of the key size value to perform encryption.

Current cryptography guidelines suggest that you use a key length of at least 2048 bits with the RSA and DSA algorithms. However, continued advancements in computing power and factoring techniques [1] mean that future increases in the recommended key size are inevitable. If user input is even used as a partial key size, it can weaken the security of the signature, and therefore the integrity of the encrypted data.

Example 1: The following code generates a DSA signature key with a user-controlled key size parameter:

...
dsa.GenerateParameters(params, rand.Reader, key_len)
privatekey := new(dsa.PrivateKey)
privatekey.PublicKey.Parameters = *params
dsa.GenerateKey(privatekey, rand.Reader)
...


Rarely do users require the ability to specify key_len. In these cases, you should verify both that it is a numeric value and that it is within a suitable value range for the key size. For most use cases, select a sufficiently large hardcoded key size.
References
[1] J. Cheng 307-digit key crack endangers 1024-bit RSA
[2] Elaine Barker and Allen Roginsky NIST Special Publication 800-131A: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths. NIST
[3] B. Chess and J. West, Secure Programming with Static Analysis. Boston, MA: Addison-Wesley, 2007.
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.5
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[8] Standards Mapping - CIS Kubernetes Benchmark complete
[9] Standards Mapping - Common Weakness Enumeration CWE ID 326
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[11] Standards Mapping - FIPS200 MP
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[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.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.8.3 Single or Multi Factor One Time Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.2.3 Algorithms (L2 L3), 6.2.4 Algorithms (L2 L3), 6.2.5 Algorithms (L2 L3), 6.2.6 Algorithms (L2 L3), 6.2.7 Algorithms (L3), 9.1.2 Communications Security Requirements (L1 L2 L3), 9.1.3 Communications Security Requirements (L1 L2 L3)
[22] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[23] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.6.1, Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.6.1, Requirement 6.3.1.3, Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.6.1, Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.6.1, Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.6.1, Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.6.1, Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.6.1, Requirement 6.5.3
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.6.1, Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[34] 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
[35] 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
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002020 CAT II, APSC-DV-002290 CAT II
desc.dataflow.golang.weak_cryptographic_signature_user_controlled_key_size
Abstract
Cryptographic signature functions that take a key size parameter should not be passed a tainted key size value.
Explanation
Allowing a user-controlled value to determine the key size may enable the attacker to specify an empty key, allowing for the modification of a cryptographic signature that ensures integrity of encrypted data. Even if a non-zero value is required, the attacker could still specify the lowest possible key size value, decreasing the integrity of the encrypted data.

Weak Cryptographic Hash: User-Controlled Key Size issues occur when:

1. Data enters a program through an untrusted source

2. User-controlled data is used as all or part of the key size parameter within a cryptographic signature function

As with many software security vulnerabilities, Weak Cryptographic Hash: User-Controlled Key Size is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application and that data is then used as all or part of the key size value while performing encryption.

Current cryptography guidelines suggest that a key length of at least 2048 bits should be used with the RSA and DSA algorithms. However, continued advancements in computing power and factoring techniques [1] mean that future increases in the recommended key size are inevitable. If user input is even used as a partial key size, it may greatly weaken the security of the signature, and therefore the integrity of the encrypted data.

Example 1: The following code generates a DSA signature key using a user-controlled key size parameter:

require 'openssl'
...
key_len = io.read.to_i
key = OpenSSL::PKey::DSA.new(key_len)
...


There are few use cases where users should be able to determine key_len, and even then there should be appropriate protection to verify both that it is a numeric value and that it is within a suitable range of values for a key size. For most use cases, this should be a sufficiently high hardcoded number.
References
[1] J. Cheng 307-digit key crack endangers 1024-bit RSA
[2] Elaine Barker and Allen Roginsky NIST Special Publication 800-131A: Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths. NIST
[3] B. Chess and J. West, Secure Programming with Static Analysis. Boston, MA: Addison-Wesley, 2007.
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.5
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[8] Standards Mapping - CIS Kubernetes Benchmark complete
[9] Standards Mapping - Common Weakness Enumeration CWE ID 326
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[11] Standards Mapping - FIPS200 MP
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-12 Cryptographic Key Establishment and Management (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-12 Cryptographic Key Establishment and Management
[15] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[16] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[17] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[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.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.8.3 Single or Multi Factor One Time Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.2.3 Algorithms (L2 L3), 6.2.4 Algorithms (L2 L3), 6.2.5 Algorithms (L2 L3), 6.2.6 Algorithms (L2 L3), 6.2.7 Algorithms (L3), 9.1.2 Communications Security Requirements (L1 L2 L3), 9.1.3 Communications Security Requirements (L1 L2 L3)
[22] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[23] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[24] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.6.1, Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.6.1, Requirement 6.3.1.3, Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.6.1, Requirement 6.5.3
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.6.1, Requirement 6.5.3
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.6.1, Requirement 6.5.3
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.6.1, Requirement 6.5.3
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.6.1, Requirement 6.5.3
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.6.1, Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.2 - Use of Cryptography
[34] 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
[35] 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
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002020 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002020 CAT II, APSC-DV-002290 CAT II
desc.dataflow.ruby.weak_cryptographic_signature_user_controlled_key_size
Abstract
The automount of API credentials is not disabled.
Explanation
Unless otherwise specified, any newly created Pod is automatically assigned a default service account. For each service account, an API access token is automatically generated and made available in a mounted directory. Attackers can use the access token in any compromised Container to gain access to insufficiently protected and security-sensitive service APIs.

The automounting of API credentials for the default service account of a Pod is not disabled because automountServiceAccountToken is not defined or the configuration of the default service account contains the automountServiceAccountToken: true setting.

Example 1: API credentials for the default service account of a Pod are automounted if the automountServiceAccountToken is not defined or is set to true, as in this example.

apiVersion: v1
kind: ServiceAccount
metadata:
name: default
namespace: demo-namespace
automountServiceAccountToken: true
...
Example 2: API credentials are automounted for a Pod because there is an automountServiceAccountToken: true setting in the default service account as in this example.

apiVersion: v1
kind: Pod
...
spec:
automountServiceAccountToken: true
...
References
[1] Configure Service Accounts for Pods The Kubernetes Authors
[2] How to _not_ create a service account? kubernetes, GitHub repository
[3] Workload Resources The Kubernetes Authors
[4] Standards Mapping - CIS Azure Kubernetes Service Benchmark 2
[5] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[6] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[7] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[8] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[9] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[10] Standards Mapping - CIS Kubernetes Benchmark complete
[11] Standards Mapping - Common Weakness Enumeration CWE ID 749
[12] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-000804, CCI-001082, CCI-001084, 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 Top 10 2010 A8 Failure to Restrict URL Access
[19] Standards Mapping - OWASP Top 10 2013 A7 Missing Function Level Access Control
[20] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[21] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[22] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[23] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.5.1 Validate HTTP Request Header Requirements (L1 L2 L3)
[24] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 7.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 7.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10
[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 3.1 Requirement 6.5.8
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[35] 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
[36] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 862
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3480.1 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3360 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3470.1 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3470.1 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3470.1 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3470.1 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3470.1 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-001870 CAT II, APSC-DV-002150 CAT II, APSC-DV-002360 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-001870 CAT II, APSC-DV-002150 CAT II, APSC-DV-002360 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-001870 CAT II, APSC-DV-002150 CAT II, APSC-DV-002360 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-001870 CAT II, APSC-DV-002150 CAT II, APSC-DV-002360 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-001870 CAT II, APSC-DV-002150 CAT II, APSC-DV-002360 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-001870 CAT II, APSC-DV-002150 CAT II, APSC-DV-002360 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-001870 CAT II, APSC-DV-002150 CAT II, APSC-DV-002360 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-001870 CAT II, APSC-DV-002150 CAT II, APSC-DV-002360 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-001870 CAT II, APSC-DV-002150 CAT II, APSC-DV-002360 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-001870 CAT II, APSC-DV-002150 CAT II, APSC-DV-002360 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-001870 CAT II, APSC-DV-002150 CAT II, APSC-DV-002360 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-001870 CAT II, APSC-DV-002150 CAT II, APSC-DV-002360 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-001870 CAT II, APSC-DV-002150 CAT II, APSC-DV-002360 CAT II
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authorization (WASC-02)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authorization
desc.structural.yaml.kubernetes_misconfiguration_service_account_token_automounted.base
Abstract
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the command that is executed. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.

2. The data is used as or as part of a string representing a command that is executed by the application.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a system utility uses the registry key APPHOME to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.


...
CALL FUNCTION 'REGISTRY_GET'
EXPORTING
KEY = 'APPHOME'
IMPORTING
VALUE = home.

CONCATENATE home INITCMD INTO cmd.
CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].
...


The code in Example 1 allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the registry entry APPHOME to point to a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the registry, if an attacker can control the value of the registry key APPHOME, then they can fool the application into running malicious code and take control of the system.

Example 2: The following code is from an administrative web application designed to allow users to kick off a backup of an Oracle database using a batch-file wrapper around the rman utility and then run a cleanup.bat script to delete some temporary files. The script rmanDB.bat accepts a single command line parameter, which specifies the type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.


...
btype = request->get_form_field( 'backuptype' )
CONCATENATE `/K 'c:\\util\\rmanDB.bat ` btype `&&c:\\util\\cleanup.bat'` INTO cmd.

CALL FUNCTION 'SXPG_COMMAND_EXECUTE_LONG'
EXPORTING
commandname = cmd_exe
long_params = cmd_string
EXCEPTIONS
no_permission = 1
command_not_found = 2
parameters_too_long = 3
security_risk = 4
OTHERS = 5.
...


The problem here is that the program does not do any validation on the backuptype parameter read from the user. Typically the function module SXPG_COMMAND_EXECUTE_LONG will not execute multiple commands, but in this case the program first runs the cmd.exe shell in order to run multiple commands with a single call to CALL 'SYSTEM'. After the shell is invoked, it will allow for the execution of multiple commands separated by two ampersands. If an attacker passes a string of the form "&& del c:\\dbms\\*.*", then the application will execute this command along with the others specified by the program. Because of the nature of the application, it runs with the privileges necessary to interact with the database, which means whatever command the attacker injects will run with those privileges as well.

Example 3: The following code is from a web application that provides an interface through which users can update their password on the system. Part of the process for updating passwords in certain network environments is to run a make command in the /var/yp directory.


...
MOVE 'make' to cmd.
CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].
...


The problem here is that the program does not specify an absolute path for make and fails to clean its environment prior to executing the call to CALL 'SYSTEM'. If an attacker can modify the $PATH variable to point to a malicious binary called make and cause the program to be executed in their environment, then the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's make will now be run with these privileges, possibly giving the attacker complete control of the system.
References
[1] SAP OSS notes 677435, 686765, 866732, 854060, 1336776, 1520462, 1530983 and related notes.
desc.dataflow.abap.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the command that is executed. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.

2. The data is used as or as part of a string representing a command that is executed by the application.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code uses input from configuration file to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.


...
var fs:FileStream = new FileStream();
fs.open(new File(String(configStream.readObject())+".txt"), FileMode.READ);
home = String(fs.readObject(home));
var cmd:String = home + INITCMD;
fscommand("exec", cmd);
...


The code in Example 1 allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the contents of the configuration file configStream to point to a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the file, if an attacker can control that value, then they can fool the application into running malicious code and take control of the system.

Example 2: The following code is from an administrative web application designed to allow users to kick off a backup of an Oracle database using a batch-file wrapper around the rman utility and then run a cleanup.bat script to delete some temporary files. The script rmanDB.bat accepts a single command line parameter, which specifies the type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.


...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var btype:String = String(params["backuptype"]);
var cmd:String = "cmd.exe /K \"c:\\util\\rmanDB.bat " + btype + "&&c:\\util\\cleanup.bat\"";
fscommand("exec", cmd);
...


The problem here is that the program does not do any validation on the backuptype parameter read from the user. Typically the fscommand() function will not execute multiple commands, but in this case the program first runs the cmd.exe shell in order to run multiple commands with a single call to fscommnd(). After the shell is invoked, it will allow for the execution of multiple commands separated by two ampersands. If an attacker passes a string of the form "&& del c:\\dbms\\*.*", then the application will execute this command along with the others specified by the program. Because of the nature of the application, it runs with the privileges necessary to interact with the database, which means whatever command the attacker injects will run with those privileges as well.

Example 3: The following code is from a web application that provides an interface through which users can update their password on the system. Part of the process for updating passwords in certain network environments is to run a make command in the /var/yp directory.


...
fscommand("exec", "make");
...


The problem here is that the program does not specify an absolute path for make and fails to clean its environment prior to executing the call to fscommand(). If an attacker can modify the $PATH variable to point to a malicious binary called make and cause the program to be executed in their environment, then the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's make will now be run with these privileges, possibly giving the attacker complete control of the system.
desc.dataflow.actionscript.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the command that is executed. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.

2. The data is used as or as part of a string representing a command that is executed by the application.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a system utility uses the system property APPHOME to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.


...
string val = Environment.GetEnvironmentVariable("APPHOME");
string cmd = val + INITCMD;
ProcessStartInfo startInfo = new ProcessStartInfo(cmd);
Process.Start(startInfo);
...


The code in Example 1 allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the system property APPHOME to point to a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the environment, if an attacker can control the value of the system property APPHOME, then they can fool the application into running malicious code and take control of the system.

Example 2: The following code is from an administrative web application designed to allow users to kick off a backup of an Oracle database using a batch-file wrapper around the rman utility and then run a cleanup.bat script to delete some temporary files. The script rmanDB.bat accepts a single command line parameter, which specifies the type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.


...
string btype = BackupTypeField.Text;
string cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat"
+ btype + "&&c:\\util\\cleanup.bat\""));
Process.Start(cmd);
...


The problem here is that the program does not do any validation on BackupTypeField. Typically the Process.Start() function will not execute multiple commands, but in this case the program first runs the cmd.exe shell in order to run multiple commands with a single call to Process.Start(). After the shell is invoked, it will allow for the execution of multiple commands separated by two ampersands. If an attacker passes a string of the form "&& del c:\\dbms\\*.*", then the application will execute this command along with the others specified by the program. Because of the nature of the application, it runs with the privileges necessary to interact with the database, which means whatever command the attacker injects will run with those privileges as well.

Example 3: The following code is from a web application that gives users access to an interface through which they can update their password on the system. Part of the process for updating passwords in this network environment is to run an update.exe command, as follows:


...
Process.Start("update.exe");
...


The problem here is that the program does not specify an absolute path and fails to clean its environment prior to executing the call to Process.start(). If an attacker can modify the $PATH variable to point to a malicious binary called update.exe and cause the program to be executed in their environment, then the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's update.exe will now be run with these privileges, possibly giving the attacker complete control of the system.
desc.dataflow.dotnet.command_injection
Abstract
Executing commands that include unvalidated user input can cause an application to act on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, in which an attacker explicitly controls the command that is executed. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.


2. The data is part of a string that is executed as a command by the application.


3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following simple program accepts a filename as a command line argument and displays the contents of the file back to the user. The program is installed setuid root because it is intended for use as a learning tool to allow system administrators in-training to inspect privileged system files without giving them the ability to modify them or damage the system.


int main(char* argc, char** argv) {
char cmd[CMD_MAX] = "/usr/bin/cat ";
strcat(cmd, argv[1]);
system(cmd);
}


Because the program runs with root privileges, the call to system() also executes with root privileges. If a user specifies a standard filename, the call works as expected. However, if an attacker passes a string of the form ";rm -rf /", then the call to system() fails to execute cat due to a lack of arguments and then plows on to recursively delete the contents of the root partition.

Example 2: The following code from a privileged program uses the environment variable $APPHOME to determine the application's installation directory and then executes an initialization script in that directory.


...
char* home=getenv("APPHOME");
char* cmd=(char*)malloc(strlen(home)+strlen(INITCMD));
if (cmd) {
strcpy(cmd,home);
strcat(cmd,INITCMD);
execl(cmd, NULL);
}
...


As in Example 1, the code in this example allows an attacker to execute arbitrary commands with the elevated privilege of the application. In this example, the attacker may modify the environment variable $APPHOME to specify a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the environment, by controlling the environment variable the attacker may fool the application into running malicious code.

The attacker is using the environment variable to control the command that the program invokes, so the effect of the environment is explicit in this example. We will now turn our attention to what can happen when the attacker may change the way the command is interpreted.

Example 3: The following code is from a web-based CGI utility that allows users to change their passwords. The password update process under NIS includes running make in the /var/yp directory. Note that since the program updates password records, it has been installed setuid root.

The program invokes make as follows:


system("cd /var/yp && make &> /dev/null");


Unlike the previous examples, the command in this example is hardcoded, so an attacker cannot control the argument passed to system(). However, since the program does not specify an absolute path for make and does not scrub any environment variables prior to invoking the command, the attacker may modify their $PATH variable to point to a malicious binary named make and execute the CGI script from a shell prompt. And since the program has been installed setuid root, the attacker's version of make now runs with root privileges.

On Windows, additional risks are present.

Example 4: When invoking CreateProcess() either directly or via a call to one of the functions in the _spawn() family, care must be taken when there is a space in an executable or path.


...
LPTSTR cmdLine = _tcsdup(TEXT("C:\\Program Files\\MyApplication -L -S"));
CreateProcess(NULL, cmdLine, ...);
...


Because of the way CreateProcess() parses spaces, the first executable the operating system will try to execute is Program.exe, not MyApplication.exe. Therefore, if an attacker is able to install a malicious application called Program.exe on the system, any program that incorrectly calls CreateProcess() using the Program Files directory will run this application instead of the intended one.

The environment plays a powerful role in the execution of system commands within programs. Functions like system(), exec(), and CreateProcess() use the environment of the program that calls them, and therefore attackers have a potential opportunity to influence the behavior of these calls.
desc.dataflow.cpp.command_injection
Abstract
Executing commands without specifying an absolute path can enable an attacker to use the program to execute a malicious binary by changing $PATH or other aspects of the program's execution environment.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls the command.

- An attacker can control parameters to the program.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the second scenario, in which an attacker can change the meaning of the command by changing an environment variable or by inserting a malicious executable early on the search path. Command injection vulnerabilities of this type occur when:

1. An attacker modifies an application's environment.

2. The application executes a command without specifying an absolute path or verifying the binary being executed.



3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: This example demonstrates what can happen when the attacker can change how a command is interpreted. The code is from a web-based CGI utility that allows users to change their passwords. The password update process under NIS includes running make in the /var/yp directory. Note that because the program updates password records, it has been installed setuid root.

The program invokes make as follows:


MOVE "cd /var/yp && make &> /dev/null" to command-line
CALL "CBL_EXEC_RUN_UNIT" USING command-line
length of command-line
run-unit-id
stack-size
flags


The command in this example is hardcoded, so an attacker cannot control the argument passed to CBL_EXEC_RUN_UNIT. However, because the program does not specify an absolute path for make and does not scrub its environment variables prior to invoking the command, the attacker can modify their $PATH variable to point to a malicious binary named make and execute the CGI script from a shell prompt. In addition, because the program has been installed setuid root, the attacker's version of make now runs with root privileges.

Example 2: The following code uses an environment variable to determine the temporary directory that contains the file to print with the pdfprint command.


DISPLAY "TEMP" UPON ENVIRONMENT-NAME
ACCEPT ws-temp-dir FROM ENVIRONMENT-VARIABLE
STRING "pdfprint " DELIMITED SIZE
ws-temp-dir DELIMITED SPACE
"/" DELIMITED SIZE
ws-pdf-filename DELIMITED SPACE
x"00" DELIMITED SIZE
INTO cmd-buffer
CALL "SYSTEM" USING cmd-buffer


Similar to the previous example, the command is hardcoded. However, because the program does not specify an absolute path for pdfprint, the attacker can modify their $PATH variable to point to a malicious binary. Furthermore, while the DELIMITED SPACE phrases prevent embedded spaces in ws-temp-dir and ws-pdf-filename, there could be shell metacharacters (such as &&) embedded in either.
desc.semantic.cobol.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the command that is executed. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.

2. The data is used as or as part of a string representing a command that is executed by the application.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code allows an attacker to specify arbitrary commands via the cmd request parameter.


...
<cfset var="#url.cmd#">
<cfexecute name = "C:\windows\System32\cmd.exe"
arguments = "/c #var#"
timeout = "1"
variable="mycmd">
</cfexecute>
...
desc.dataflow.cfml.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker can control the command that is executed. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.

2. The data is used as or as part of a string representing a command that is executed by the application.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a system utility uses the system property APPHOME to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.


...
final cmd = String.fromEnvironment('APPHOME');
await Process.run(cmd);
...


The code in Example 1 allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the system property APPHOME to point to a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the environment, if an attacker can control the value of the system property APPHOME, then they can fool the application into running malicious code and take control of the system.
desc.dataflow.dart.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls the command.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker can control the executed command. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.


2. The data is used as or as part of a string that represents a command the application executes.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example: The following code runs a user-controller command.


cmdName := request.FormValue("Command")
c := exec.Command(cmdName)
c.Run()
desc.dataflow.golang.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the command that is executed. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.

2. The data is used as or as part of a string representing a command that is executed by the application.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a system utility uses the system property APPHOME to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.


...
String home = System.getProperty("APPHOME");
String cmd = home + INITCMD;
java.lang.Runtime.getRuntime().exec(cmd);
...


The code in Example 1 allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the system property APPHOME to point to a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the environment, if an attacker can control the value of the system property APPHOME, then they can fool the application into running malicious code and take control of the system.

Example 2: The following code is from an administrative web application designed to allow users to kick off a backup of an Oracle database using a batch-file wrapper around the rman utility and then run a cleanup.bat script to delete some temporary files. The script rmanDB.bat accepts a single command line parameter, which specifies the type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.


...
String btype = request.getParameter("backuptype");
String cmd = new String("cmd.exe /K
\"c:\\util\\rmanDB.bat "+btype+"&&c:\\util\\cleanup.bat\"")
System.Runtime.getRuntime().exec(cmd);
...


The problem here is that the program does not do any validation on the backuptype parameter read from the user. Typically the Runtime.exec() function will not execute multiple commands, but in this case the program first runs the cmd.exe shell in order to run multiple commands with a single call to Runtime.exec(). After the shell is invoked, it will allow for the execution of multiple commands separated by two ampersands. If an attacker passes a string of the form "&& del c:\\dbms\\*.*", then the application will execute this command along with the others specified by the program. Because of the nature of the application, it runs with the privileges necessary to interact with the database, which means whatever command the attacker injects will run with those privileges as well.

Example 3: The following code is from a web application that provides an interface through which users can update their password on the system. Part of the process for updating passwords in certain network environments is to run a make command in the /var/yp directory.


...
System.Runtime.getRuntime().exec("make");
...


The problem here is that the program does not specify an absolute path for make and fails to clean its environment prior to executing the call to Runtime.exec(). If an attacker can modify the $PATH variable to point to a malicious binary called make and cause the program to be executed in their environment, then the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's make will now be run with these privileges, possibly giving the attacker complete control of the system.

Some think that in the mobile world, classic vulnerabilities, such as command injection, do not make sense -- why would a user attack him or herself? However, keep in mind that the essence of mobile platforms is applications that are downloaded from various sources and run alongside each other on the same device. The likelihood of running a piece of malware next to a banking application is high, which necessitates expanding the attack surface of mobile applications to include inter-process communication.

Example 4: The following code reads commands to be executed from an Android intent.


...
String[] cmds = this.getIntent().getStringArrayExtra("commands");
Process p = Runtime.getRuntime().exec("su");
DataOutputStream os = new DataOutputStream(p.getOutputStream());
for (String cmd : cmds) {
os.writeBytes(cmd+"\n");
}
os.writeBytes("exit\n");
os.flush();
...


On a rooted device, a malicious application can force a victim application to execute arbitrary commands with super user privileges.
References
[1] IDS07-J. Sanitize untrusted data passed to the Runtime.exec() method CERT
desc.dataflow.java.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the command that is executed. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.


2. The data is used as or as part of a string representing a command that is executed by the application.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a system utility uses the environment variable APPHOME to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.


var cp = require('child_process');
...
var home = process.env('APPHOME');
var cmd = home + INITCMD;
child = cp.exec(cmd, function(error, stdout, stderr){
...
});
...


The code in Example 1 allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the system property APPHOME to point to a different path containing a malicious version of INITCMD. Since the program does not validate the value read from the environment, if an attacker can control the value of the system property APPHOME, then they can fool the application into running malicious code and take control of the system.

Example 2: The following code is from an administrative web application designed to allow users to kick off a backup of an Oracle database using a batch-file wrapper around the rman utility. The script rmanDB.bat accepts a single command line parameter, which specifies the type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.


var cp = require('child_process');
var http = require('http');
var url = require('url');

function listener(request, response){
var btype = url.parse(request.url, true)['query']['backuptype'];
if (btype !== undefined){
cmd = "c:\\util\\rmanDB.bat" + btype;
cp.exec(cmd, function(error, stdout, stderr){
...
});
}
...
}
...
http.createServer(listener).listen(8080);


The problem here is that the program does not do any validation on the backuptype parameter read from the user apart from verifying its existence. After the shell is invoked, it may allow for the execution of multiple commands, and due to the nature of the application, it will run with the privileges necessary to interact with the database, which means whatever command the attacker injects will run with those privileges as well.

Example 3: The following code is from a web application that provides an interface through which users can update their password on the system. Part of the process for updating passwords in certain network environments is to run a make command in the /var/yp directory.


...
require('child_process').exec("make", function(error, stdout, stderr){
...
});
...


The problem here is that the program does not specify an absolute path for make and fails to clean its environment prior to executing the call to child_process.exec(). If an attacker can modify the $PATH variable to point to a malicious binary called make and cause the program to be executed in their environment, then the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's make will now be run with these privileges, possibly giving the attacker complete control of the system.
desc.dataflow.javascript.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the command that is executed. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.

2. The data is used as or as part of a string representing a command that is executed by the application.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a system utility uses the system property APPHOME to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.


...
$home = $_ENV['APPHOME'];
$cmd = $home . $INITCMD;
system(cmd);
...


The code in Example 1 allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the system property APPHOME to point to a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the environment, if an attacker can control the value of the system property APPHOME, then they can fool the application into running malicious code and take control of the system.

Example 2: The following code is from an administrative web application designed to allow users to kick off a backup of an Oracle database using a batch-file wrapper around the rman utility and then run a cleanup.bat script to delete some temporary files. The script rmanDB.bat accepts a single command line parameter, which specifies the type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.


...
$btype = $_GET['backuptype'];
$cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " . $btype . "&&c:\\util\\cleanup.bat\"";
system(cmd);
...


The problem here is that the program does not do any validation on the backuptype parameter read from the user. Typically the Runtime.exec() function will not execute multiple commands, but in this case the program first runs the cmd.exe shell in order to run multiple commands with a single call to Runtime.exec(). After the shell is invoked, it will allow for the execution of multiple commands separated by two ampersands. If an attacker passes a string of the form "&& del c:\\dbms\\*.*", then the application will execute this command along with the others specified by the program. Because of the nature of the application, it runs with the privileges necessary to interact with the database, which means whatever command the attacker injects will run with those privileges as well.

Example 3: The following code is from a web application that provides an interface through which users can update their password on the system. Part of the process for updating passwords in certain network environments is to run a make command in the /var/yp directory.


...
$result = shell_exec("make");
...


The problem here is that the program does not specify an absolute path for make and fails to clean its environment prior to executing the call to Runtime.exec(). If an attacker can modify the $PATH variable to point to a malicious binary called make and cause the program to be executed in their environment, then the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's make will now be run with these privileges, possibly giving the attacker complete control of the system.
desc.dataflow.php.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the command that is executed. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.

2. The data is used as or as part of a string representing a command that is executed by the application.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example: The following code defines a T-SQL stored procedure that, when called with untrusted data, will execute a system command controlled by an attacker.


...
CREATE PROCEDURE dbo.listFiles (@path NVARCHAR(200))
AS

DECLARE @cmd NVARCHAR(500)
SET @cmd = 'dir ' + @path

exec xp_cmdshell @cmd

GO
...
References
[1] xp_cmdshell
desc.dataflow.sql.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the command that is executed. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.

2. The data is used as or as part of a string representing a command that is executed by the application.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a system utility uses the system property APPHOME to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.


...
home = os.getenv('APPHOME')
cmd = home.join(INITCMD)
os.system(cmd);
...


The code in Example 1 allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the system property APPHOME to point to a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the environment, if an attacker can control the value of the system property APPHOME, then they can fool the application into running malicious code and take control of the system.

Example 2: The following code is from an administrative web application designed to allow users to kick off a backup of an Oracle database using a batch-file wrapper around the rman utility and then run a cleanup.bat script to delete some temporary files. The script rmanDB.bat accepts a single command line parameter, which specifies the type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.


...
btype = req.field('backuptype')
cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " + btype + "&&c:\\util\\cleanup.bat\""
os.system(cmd);
...


The problem here is that the program does not do any validation on the backuptype parameter read from the user. Typically the Runtime.exec() function will not execute multiple commands, but in this case the program first runs the cmd.exe shell in order to run multiple commands with a single call to Runtime.exec(). After the shell is invoked, it will allow for the execution of multiple commands separated by two ampersands. If an attacker passes a string of the form "&& del c:\\dbms\\*.*", then the application will execute this command along with the others specified by the program. Because of the nature of the application, it runs with the privileges necessary to interact with the database, which means whatever command the attacker injects will run with those privileges as well.

Example 3: The following code is from a web application that provides an interface through which users can update their password on the system. Part of the process for updating passwords in certain network environments is to run a make command in the /var/yp directory.


...
result = os.system("make");
...


The problem here is that the program does not specify an absolute path for make and fails to clean its environment prior to executing the call to os.system(). If an attacker can modify the $PATH variable to point to a malicious binary called make and cause the program to be executed in their environment, then the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's make will now be run with these privileges, possibly giving the attacker complete control of the system.
desc.dataflow.python.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the command that is executed. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.


2. The data is used as or as part of a string representing a command that is executed by the application.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a system utility uses the system property APPHOME to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.


...
home = ENV['APPHOME']
cmd = home + INITCMD
Process.spawn(cmd)
...


The code in Example 1 allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the system property APPHOME to point to a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the environment, if an attacker can control the value of the system property APPHOME, then they can fool the application into running malicious code and take control of the system.

Example 2: The following code is from an administrative web application designed to allow users to kick off a backup of an Oracle database using a batch-file wrapper around the rman utility and then run a cleanup.bat script to delete some temporary files. The script rmanDB.bat accepts a single command line parameter, which specifies the type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.


...
btype = req['backuptype']
cmd = "C:\\util\\rmanDB.bat #{btype} &&C:\\util\\cleanup.bat"
spawn(cmd)
...


The problem here is that the program does not do any validation on the backuptype parameter read from the user. After the shell is invoked via Kernel.spawn, it will allow for the execution of multiple commands separated by two ampersands. If an attacker passes a string of the form "&& del c:\\dbms\\*.*", then the application will execute this command along with the others specified by the program. Because of the nature of the application, it runs with the privileges necessary to interact with the database, which means whatever command the attacker injects will run with those privileges as well.

Example 3: The following code is from a web application that provides an interface through which users can update their password on the system. Part of the process for updating passwords in certain network environments is to run a make command in the /var/yp directory.


...
system("make")
...


The problem here is that the program does not specify an absolute path for make and fails to clean its environment prior to executing the call to Kernel.system(). If an attacker can modify the $PATH variable to point to a malicious binary called make and cause the program to be executed in their environment, then the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's make will now be run with these privileges, possibly giving the attacker complete control of the system.
desc.dataflow.ruby.command_injection
Abstract
Executing commands that include unvalidated user input can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the second scenario, the possibility that an attacker may be able to change the meaning of the command by changing an environment variable or by putting a malicious executable early in the search path. Command injection vulnerabilities of this type occur when:

1. An attacker modifies an application's environment.

2. The application executes a command without specifying an absolute path or verifying the binary being executed.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example: The following code is from a web application that provides an interface through which users can update their password on the system.


def changePassword(username: String, password: String) = Action { request =>
...
s'echo "${password}" | passwd ${username} --stdin'.!
...
}
References
[1] IDS07-J. Sanitize untrusted data passed to the Runtime.exec() method CERT
desc.dataflow.scala.command_injection
Abstract
Executing commands from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Command injection vulnerabilities take two forms:

- An attacker can change the command that the program executes: the attacker explicitly controls what the command is.

- An attacker can change the environment in which the command executes: the attacker implicitly controls what the command means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the command that is executed. Command injection vulnerabilities of this type occur when:

1. Data enters the application from an untrusted source.

2. The data is used as or as part of a string representing a command that is executed by the application.

3. By executing the command, the application gives an attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code from a system utility uses the system property APPHOME to determine the directory in which it is installed and then executes an initialization script based on a relative path from the specified directory.


...
Dim cmd
Dim home

home = Environ$("AppHome")
cmd = home & initCmd
Shell cmd, vbNormalFocus
...


The code in Example 1 allows an attacker to execute arbitrary commands with the elevated privilege of the application by modifying the system property APPHOME to point to a different path containing a malicious version of INITCMD. Because the program does not validate the value read from the environment, if an attacker can control the value of the system property APPHOME, then they can fool the application into running malicious code and take control of the system.

Example 2: The following code is from an administrative web application designed to allow users to kick off a backup of an Oracle database using a batch-file wrapper around the rman utility and then run a cleanup.bat script to delete some temporary files. The script rmanDB.bat accepts a single command line parameter, which specifies the type of backup to perform. Because access to the database is restricted, the application runs the backup as a privileged user.


...
btype = Request.Form("backuptype")
cmd = "cmd.exe /K " & Chr(34) & "c:\util\rmanDB.bat " & btype & "&&c:\util\cleanup.bat" & Chr(34) & ";
Shell cmd, vbNormalFocus
...


The problem here is that the program does not do any validation on the backuptype parameter read from the user. After the shell is invoked, it will allow for the execution of multiple commands separated by two ampersands. If an attacker passes a string of the form "&& del c:\\dbms\\*.*", then the application will execute this command along with the others specified by the program. Because of the nature of the application, it runs with the privileges necessary to interact with the database, which means whatever command the attacker injects will run with those privileges as well.

Example 3: The following code is from a web application that provides an interface through which users can update their password on the system. Part of the process for updating passwords in certain network environments is to run a make command in the /var/yp directory.


...
$result = shell_exec("make");
...


The problem here is that the program does not specify an absolute path for make and fails to clean its environment prior to executing the call to Runtime.exec(). If an attacker can modify the $PATH variable to point to a malicious binary called make and cause the program to be executed in their environment, then the malicious binary will be loaded instead of the one intended. Because of the nature of the application, it runs with the privileges necessary to perform system operations, which means the attacker's make will now be run with these privileges, possibly giving the attacker complete control of the system.
desc.dataflow.vb.command_injection
Abstract
Impersonating user credentials could allow an attacker to gain unauthorized access to protected resources.
Explanation
Microsoft ASP.NET applications can impersonate the security context of the current user or the process that invoked them in order to execute privileged operations. Although impersonation contexts serve a variety of useful purposes, such as reducing the overall number of authentication attempts that must be made, a program that retains elevated privileges unnecessarily poses a risk to the overall security of the system. If an attacker exploits another vulnerability in the program while it is running in another security context, any unauthorized operations the attacker performs will be executed with the corresponding privileges.

Example 1: The following code example represents a typical use pattern for impersonating credentials using the WindowsIdentity.Impersonate() method.


using System.Security.Principal;
...

//Get the identity of the current user
IIdentity contextId = HttpContext.Current.User.Identity;
WindowsIdentity userId = (WindowsIdentity)contextId;

//Temporarily impersonate
WindowsImpersonationContext imp = userId.Impersonate();

//Perform tasks using the caller's security context
DoSecuritySensitiveTasks();

//Clean up and restore our old security context
impersonate.Undo();


The code in Example 1 impersonates the current user's security context and uses it to perform a privileged operation. After calling DoSecuritySensitiveTasks(), the code attempts to restore the original security context, but if DoSecuritySensitiveTasks() throws an exception, the Undo() method will never be called and the program will continue to use the impersonated security context.
References
[1] Kirk Evans Security Practices: ASP.NET 2.0 Security Practices at a Glance Microsoft Corporation
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 520
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [22] CWE ID 269
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[9] Standards Mapping - FIPS200 AC
[10] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[13] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[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 14.1.3 Build (L2 L3)
[19] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[20] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.7
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10
[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
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3480.1 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3480.1 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3480.1 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3480.1 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3480.1 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3480.1 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3480.1 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-001410 CAT II, APSC-DV-001520 CAT II, APSC-DV-001530 CAT II
[53] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authorization (WASC-02)
[54] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authorization
desc.controlflow.dotnet.asp_dotnet_bad_practices_use_of_impersonation_context
Abstract
Configuring an ASP.NET application to run with impersonated credentials might give the application unnecessary privileges.
Explanation
The use of impersonated credentials allows an ASP.NET application to run with either the privileges of the client on whose behalf it is executing or with arbitrary privileges granted in its configuration.
References
[1] How to implement impersonation in an ASP.NET application Microsoft
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[6] Standards Mapping - CIS Kubernetes Benchmark complete
[7] Standards Mapping - Common Weakness Enumeration CWE ID 556
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [22] CWE ID 269
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[10] Standards Mapping - FIPS200 CM
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[14] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[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 API 2023 API8 Security Misconfiguration
[20] Standards Mapping - OWASP Application Security Verification Standard 4.0 14.1.3 Build (L2 L3)
[21] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[22] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.7
[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.10
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10
[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 4.2 - Critical Asset Protection
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3480.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3480.1 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3480.1 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3480.1 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3480.1 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3480.1 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3480.1 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authorization (WASC-02)
[56] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authorization
desc.config.dotnet.asp_dotnet_misconfiguration_use_of_impersonation_context
Abstract
The method writes unvalidated input into JSON. This call might allow an attacker to inject arbitrary elements or attributes into the JSON entity.
Explanation
JSON injection occurs when:

1. Data enters a program from an untrusted source.


2. The data is written to a JSON stream.

Applications typically use JSON to store data or send messages. When used to store data, JSON is often treated like cached data and may potentially contain sensitive information. When used to send messages, JSON is often used in conjunction with a RESTful service and can be used to transmit sensitive information such as authentication credentials.

The semantics of JSON documents and messages can be altered if an application constructs JSON from unvalidated input. In a relatively benign case, an attacker may be able to insert extraneous elements that cause an application to throw an exception while parsing a JSON document or request. In a more serious case, such as ones that involves JSON injection, an attacker may be able to insert extraneous elements that allow for the predictable manipulation of business critical values within a JSON document or request. In some cases, JSON injection can lead to cross-site scripting or dynamic code evaluation.

Example 1: The following C# code uses JSON.NET to serialize user account authentication information for non-privileged users (those with a role of "default" as opposed to privileged users with a role of "admin") from user-controlled input variables username and password to the JSON file located at C:\user_info.json:


...

StringBuilder sb = new StringBuilder();
StringWriter sw = new StringWriter(sb);

using (JsonWriter writer = new JsonTextWriter(sw))
{
writer.Formatting = Formatting.Indented;

writer.WriteStartObject();

writer.WritePropertyName("role");
writer.WriteRawValue("\"default\"");

writer.WritePropertyName("username");
writer.WriteRawValue("\"" + username + "\"");

writer.WritePropertyName("password");
writer.WriteRawValue("\"" + password + "\"");

writer.WriteEndObject();
}

File.WriteAllText(@"C:\user_info.json", sb.ToString());


Yet, because the JSON serialization is performed using JsonWriter.WriteRawValue(), the untrusted data in username and password will not be validated to escape JSON-related special characters. This allows a user to arbitrarily insert JSON keys, possibly changing the structure of the serialized JSON. In this example, if the non-privileged user mallory with password Evil123! were to append ","role":"admin to her username when entering it at the prompt that sets the value of the username variable, the resulting JSON saved to C:\user_info.json would be:


{
"role":"default",
"username":"mallory",
"role":"admin",
"password":"Evil123!"
}


If this serialized JSON file were then deserialized to a Dictionary object with JsonConvert.DeserializeObject() as so:


String jsonString = File.ReadAllText(@"C:\user_info.json");

Dictionary<string, string> userInfo = JsonConvert.DeserializeObject<Dictionary<string, strin>>(jsonString);


The resulting values for the username, password, and role keys in the Dictionary object would be mallory, Evil123!, and admin respectively. Without further verification that the deserialized JSON values are valid, the application will incorrectly assign user mallory "admin" privileges.
desc.dataflow.dotnet.json_injection
Abstract
The method writes unvalidated input to JSON. An attacker can inject arbitrary elements or attributes into the JSON entity.
Explanation
JSON injection occurs when:

1. Data enters a program from an untrusted source.


2. The data is written to a JSON stream.

Applications typically use JSON to store data or send messages. When used to store data, JSON is often treated like cached data and might contain sensitive information. When used to send messages, JSON is often used in conjunction with a RESTful service and can transmit sensitive information such as authentication credentials.

Attackers can alter the semantics of JSON documents and messages if an application constructs JSON from unvalidated input. In a relatively benign case, an attacker can insert extraneous elements that cause an application to throw an exception while parsing a JSON document or request. In more serious cases, such as those that involves JSON injection, an attacker can insert extraneous elements that allow for the predictable manipulation of business critical values within a JSON document or request. Sometimes JSON injection can lead to cross-site scripting or dynamic code evaluation.

Example 1: The following code serializes user account authentication information for non-privileged users (those with a role of "default" as opposed to privileged users with a role of "admin") from user-controlled input variables username and password to the JSON file located at ~/user_info.json:


...
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
username := r.FormValue("username")
password := r.FormValue("password")
...
jsonString := `{
"username":"` + username + `",
"role":"default"
"password":"` + password + `",
}`
...
f, err := os.Create("~/user_info.json")
defer f.Close()

jsonEncoder := json.NewEncoder(f)
jsonEncoder.Encode(jsonString)
}


Because the code performs the JSON serialization using string concatenation, the untrusted data in username and password is not validated to escape JSON-related special characters. This allows a user to arbitrarily insert JSON keys, which can possibly change the serialized JSON structure. In this example, if the non-privileged user mallory with password Evil123! appended ","role":"admin when she entered her username, the resulting JSON saved to ~/user_info.json would be:


{
"username":"mallory",
"role":"default",
"password":"Evil123!",
"role":"admin"
}

Without further verification that the deserialized JSON values are valid, the application unintentionally assigns user mallory "admin" privileges.
desc.dataflow.golang.json_injection
Abstract
The method writes unvalidated input into JSON. This call might allow an attacker to inject arbitrary elements or attributes into the JSON entity.
Explanation
JSON injection occurs when:

1. Data enters a program from an untrusted source.


2. The data is written to a JSON stream.

Applications typically use JSON to store data or send messages. When used to store data, JSON is often treated like cached data and may potentially contain sensitive information. When used to send messages, JSON is often used in conjunction with a RESTful service and can be used to transmit sensitive information such as authentication credentials.

The semantics of JSON documents and messages can be altered if an application constructs JSON from unvalidated input. In a relatively benign case, an attacker may be able to insert extraneous elements that cause an application to throw an exception while parsing a JSON document or request. In a more serious case, such as ones that involves JSON injection, an attacker may be able to insert extraneous elements that allow for the predictable manipulation of business critical values within a JSON document or request. In some cases, JSON injection can lead to cross-site scripting or dynamic code evaluation.

Example 1: The following Java code uses Jackson to serialize user account authentication information for non-privileged users (those with a role of "default" as opposed to privileged users with a role of "admin") from user-controlled input variables username and password to the JSON file located at ~/user_info.json:


...

JsonFactory jfactory = new JsonFactory();

JsonGenerator jGenerator = jfactory.createJsonGenerator(new File("~/user_info.json"), JsonEncoding.UTF8);

jGenerator.writeStartObject();

jGenerator.writeFieldName("username");
jGenerator.writeRawValue("\"" + username + "\"");

jGenerator.writeFieldName("password");
jGenerator.writeRawValue("\"" + password + "\"");

jGenerator.writeFieldName("role");
jGenerator.writeRawValue("\"default\"");

jGenerator.writeEndObject();

jGenerator.close();


Yet, because the JSON serialization is performed using JsonGenerator.writeRawValue(), the untrusted data in username and password will not be validated to escape JSON-related special characters. This allows a user to arbitrarily insert JSON keys, possibly changing the structure of the serialized JSON. In this example, if the non-privileged user mallory with password Evil123! were to append ","role":"admin to her username when entering it at the prompt that sets the value of the username variable, the resulting JSON saved to ~/user_info.json would be:


{
"username":"mallory",
"role":"admin",
"password":"Evil123!",
"role":"default"
}


If this serialized JSON file were then deserialized to an HashMap object with Jackson's JsonParser as so:


JsonParser jParser = jfactory.createJsonParser(new File("~/user_info.json"));

while (jParser.nextToken() != JsonToken.END_OBJECT) {

String fieldname = jParser.getCurrentName();

if ("username".equals(fieldname)) {
jParser.nextToken();
userInfo.put(fieldname, jParser.getText());
}

if ("password".equals(fieldname)) {
jParser.nextToken();
userInfo.put(fieldname, jParser.getText());
}

if ("role".equals(fieldname)) {
jParser.nextToken();
userInfo.put(fieldname, jParser.getText());
}

if (userInfo.size() == 3)
break;
}

jParser.close();


The resulting values for the username, password, and role keys in the HashMap object would be mallory, Evil123!, and admin respectively. Without further verification that the deserialized JSON values are valid, the application will incorrectly assign user mallory "admin" privileges.
desc.dataflow.java.json_injection
Abstract
The method writes unvalidated input into JSON. This call might allow an attacker to inject arbitrary elements or attributes into the JSON entity.
Explanation
JSON injection occurs when:

1. Data enters a program from an untrusted source.


2. The data is written to a JSON stream.

Applications typically use JSON to store data or send messages. When used to store data, JSON is often treated like cached data and may potentially contain sensitive information. When used to send messages, JSON is often used in conjunction with a RESTful service and can be used to transmit sensitive information such as authentication credentials.

The semantics of JSON documents and messages can be altered if an application constructs JSON from unvalidated input. In a relatively benign case, an attacker may be able to insert extraneous elements that cause an application to throw an exception while parsing a JSON document or request. In a more serious case, such as ones that involves JSON injection, an attacker may be able to insert extraneous elements that allow for the predictable manipulation of business critical values within a JSON document or request. In some cases, JSON injection can lead to cross-site scripting or dynamic code evaluation.

Example 1: The following JavaScript code uses jQuery to parse JSON where a value comes from a URL:


var str = document.URL;
var url_check = str.indexOf('name=');
var name = null;
if (url_check > -1) {
name = decodeURIComponent(str.substring((url_check+5), str.length));
}

$(document).ready(function(){
if (name !== null){
var obj = jQuery.parseJSON('{"role": "user", "name" : "' + name + '"}');
...
}
...
});


Here the untrusted data in name will not be validated to escape JSON-related special characters. This allows a user to arbitrarily insert JSON keys, possibly changing the structure of the serialized JSON. In this example, if the non-privileged user mallory were to append ","role":"admin to the name parameter in the URL, the JSON would become:


{
"role":"user",
"username":"mallory",
"role":"admin"
}


This is parsed by jQuery.parseJSON() and set to a plain object, meaning that obj.role would now return "admin" instead of "user"
desc.dataflow.javascript.json_injection
Abstract
The method writes unvalidated input into JSON. This call might allow an attacker to inject arbitrary elements or attributes into the JSON entity.
Explanation
JSON injection occurs when:

1. Data enters a program from an untrusted source.


2. The data is written to a JSON stream.

Applications typically use JSON to store data or send messages. When used to store data, JSON is often treated like cached data and may potentially contain sensitive information. When used to send messages, JSON is often used in conjunction with a RESTful service and can be used to transmit sensitive information such as authentication credentials.

The semantics of JSON documents and messages can be altered if an application constructs JSON from unvalidated input. In a relatively benign case, an attacker may be able to insert extraneous elements that cause an application to throw an exception while parsing a JSON document or request. In a more serious case, such as ones that involves JSON injection, an attacker may be able to insert extraneous elements that allow for the predictable manipulation of business critical values within a JSON document or request. In some cases, JSON injection can lead to cross-site scripting or dynamic code evaluation.

Example 1: The following Objective-C code serializes user account authentication information for non-privileged users (those with a role of "default" as opposed to privileged users with a role of "admin") to JSON from user-controllable fields _usernameField and _passwordField:


...

NSString * const jsonString = [NSString stringWithFormat: @"{\"username\":\"%@\",\"password\":\"%@\",\"role\":\"default\"}" _usernameField.text, _passwordField.text];


Yet, because the JSON serialization is performed using NSString.stringWithFormat:, the untrusted data in _usernameField and _passwordField will not be validated to escape JSON-related special characters. This allows a user to arbitrarily insert JSON keys, possibly changing the structure of the serialized JSON. In this example, if the non-privileged user mallory with password Evil123! were to append ","role":"admin to her username when entering it into the _usernameField field, the resulting JSON would be:


{
"username":"mallory",
"role":"admin",
"password":"Evil123!",
"role":"default"
}


If this serialized JSON string were then deserialized to an NSDictionary object with NSJSONSerialization.JSONObjectWithData: as so:


NSError *error;
NSDictionary *jsonData = [NSJSONSerialization JSONObjectWithData:[jsonString dataUsingEncoding:NSUTF8StringEncoding] options:NSJSONReadingAllowFragments error:&error];


The resulting values for username, password, and role in the NSDictionary object would be mallory, Evil123!, and admin respectively. Without further verification that the deserialized JSON values are valid, the application will incorrectly assign user mallory "admin" privileges.
desc.dataflow.objc.json_injection
Abstract
The method writes unvalidated input into JSON. This call might allow an attacker to inject arbitrary elements or attributes into the JSON entity.
Explanation
JSON injection occurs when:

1. Data enters a program from an untrusted source.


2. The data is written to a JSON stream.

Applications typically use JSON to store data or send messages. When used to store data, JSON is often treated like cached data and may potentially contain sensitive information. When used to send messages, JSON is often used in conjunction with a RESTful service and can be used to transmit sensitive information such as authentication credentials.

The semantics of JSON documents and messages can be altered if an application constructs JSON from unvalidated input. In a relatively benign case, an attacker may be able to insert extraneous elements that cause an application to throw an exception while parsing a JSON document or request. In a more serious case, such as ones that involves JSON injection, an attacker may be able to insert extraneous elements that allow for the predictable manipulation of business critical values within a JSON document or request. In some cases, JSON injection can lead to cross-site scripting or dynamic code evaluation.

Example : The following python code update a json file with an untrusted value comes from a URL:


import json
import requests
from urllib.parse import urlparse
from urllib.parse import parse_qs

url = 'https://www.example.com/some_path?name=some_value'
parsed_url = urlparse(url)
untrusted_values = parse_qs(parsed_url.query)['name'][0]

with open('data.json', 'r') as json_File:
data = json.load(json_File)

data['name']= untrusted_values

with open('data.json', 'w') as json_File:
json.dump(data, json_File)

...


Here the untrusted data in name will not be validated to escape JSON-related special characters. This allows a user to arbitrarily insert JSON keys, possibly changing the structure of the serialized JSON. In this example, if the non-privileged user mallory were to append ","role":"admin to the name parameter in the URL, the JSON would become:


{
"role":"user",
"username":"mallory",
"role":"admin"
}

The JSON file is now tampered with malicious data and the user has a privileged access of "admin" instead of "user"
desc.dataflow.python.json_injection
Abstract
The method writes unvalidated input into JSON. This call might allow an attacker to inject arbitrary elements or attributes into the JSON entity.
Explanation
JSON injection occurs when:

1. Data enters a program from an untrusted source.


2. The data is written to a JSON stream.

Applications typically use JSON to store data or send messages. When used to store data, JSON is often treated like cached data and may potentially contain sensitive information. When used to send messages, JSON is often used in conjunction with a RESTful service and can be used to transmit sensitive information such as authentication credentials.

The semantics of JSON documents and messages can be altered if an application constructs JSON from unvalidated input. In a relatively benign case, an attacker may be able to insert extraneous elements that cause an application to throw an exception while parsing a JSON document or request. In a more serious case, such as ones that involves JSON injection, an attacker may be able to insert extraneous elements that allow for the predictable manipulation of business critical values within a JSON document or request. In some cases, JSON injection can lead to cross-site scripting or dynamic code evaluation.
desc.dataflow.scala.json_injection
Abstract
The method writes unvalidated input into JSON. This call might allow an attacker to inject arbitrary elements or attributes into the JSON entity.
Explanation
JSON injection occurs when:

1. Data enters a program from an untrusted source.


2. The data is written to a JSON stream.

Applications typically use JSON to store data or send messages. When used to store data, JSON is often treated like cached data and may potentially contain sensitive information. When used to send messages, JSON is often used in conjunction with a RESTful service and can be used to transmit sensitive information such as authentication credentials.

The semantics of JSON documents and messages can be altered if an application constructs JSON from unvalidated input. In a relatively benign case, an attacker may be able to insert extraneous elements that cause an application to throw an exception while parsing a JSON document or request. In a more serious case, such as ones that involves JSON injection, an attacker may be able to insert extraneous elements that allow for the predictable manipulation of business critical values within a JSON document or request. In some cases, JSON injection can lead to cross-site scripting or dynamic code evaluation.

Example 1: The following Swift code serializes user account authentication information for non-privileged users (those with a role of "default" as opposed to privileged users with a role of "admin") to JSON from user-controllable fields usernameField and passwordField:


...
let jsonString : String = "{\"username\":\"\(usernameField.text)\",\"password\":\"\(passwordField.text)\",\"role\":\"default\"}"


Yet, because the JSON serialization is performed using string interpolation, the untrusted data in usernameField and passwordField will not be validated to escape JSON-related special characters. This allows a user to arbitrarily insert JSON keys, possibly changing the structure of the serialized JSON. In this example, if the non-privileged user mallory with password Evil123! were to append ","role":"admin to her username when entering it into the usernameField field, the resulting JSON would be:


{
"username":"mallory",
"role":"admin",
"password":"Evil123!",
"role":"default"
}


If this serialized JSON string were then deserialized to an NSDictionary object with NSJSONSerialization.JSONObjectWithData: as so:


var error: NSError?
var jsonData : NSDictionary = NSJSONSerialization.JSONObjectWithData(jsonString.dataUsingEncoding(NSUTF8StringEncoding), options: NSJSONReadingOptions.MutableContainers, error: &error) as NSDictionary


The resulting values for username, password, and role in the NSDictionary object would be mallory, Evil123!, and admin respectively. Without further verification that the deserialized JSON values are valid, the application will incorrectly assign user mallory "admin" privileges.
desc.dataflow.swift.json_injection
Abstract
A Terraform configuration enables certificate-based authentication on a GKE cluster.
Explanation
By default, the certificate-based authentication is disabled on new clusters that run GKE version 1.12 and later. With certificate-based authentication, a user presents a certificate that the Kubernetes API server verifies with the specified certificate authority. However, there is no way to revoke the certificate when the user leaves or loses the credentials. This makes the certificate-based authentication unsuitable for end users.

Example 1: The following example Terraform configuration enables GKE client certificate-based authentication by setting issue_client_certificate to true in the master_auth block.

resource "google_container_cluster" "container_cluster_demo" {
...
master_auth {
client_certificate_config {
issue_client_certificate = true
...
}
...
}
...
}
References
[1] HashiCorp google_container_cluster
[2] Google Cloud Leave legacy client authentication methods disabled
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 3.5
[4] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[5] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[6] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[7] Standards Mapping - CIS Google Cloud Computing Platform Benchmark complete
[8] Standards Mapping - CIS Google Kubernetes Engine Benchmark confidentiality
[9] Standards Mapping - CIS Kubernetes Benchmark complete
[10] Standards Mapping - Common Weakness Enumeration CWE ID 287
[11] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287
[12] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287
[13] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[14] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001958
[15] Standards Mapping - FIPS200 IA
[16] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[17] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-5 Authenticator Management (P1)
[18] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-5 Authenticator Management
[19] Standards Mapping - OWASP Top 10 2017 A2 Broken Authentication
[20] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[21] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[22] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.2.3 Authentication Architectural Requirements (L2 L3)
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10
[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.11 APSC-DV-001650 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001650 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001650 CAT II
desc.structural.hcl.gcp_terraform_misconfiguration_gke_cluster_certificate_based_authentication