1576 items found
Weaknesses
Abstract
Relying on proper string termination could result in a buffer overflow.
Explanation
String termination errors occur when:

1. Data enters a program via a function that does not null-terminate its output.

2. The data is passed to a function that requires its input to be null-terminated.
Example 1: The following code reads from cfgfile and copies the input into inputbuf using strcpy(). The code mistakenly assumes that inputbuf will always contain a null-terminator.


#define MAXLEN 1024
...
char *pathbuf[MAXLEN];
...
read(cfgfile,inputbuf,MAXLEN); //does not null-terminate
strcpy(pathbuf,inputbuf); //requires null-terminated input
...


The code in Example 1 will behave correctly if the data read from cfgfile is null-terminated on disk as expected. But if an attacker is able to modify this input so that it does not contain the expected null character, the call to strcpy() will continue copying from memory until it encounters an arbitrary null character. This will likely overflow the destination buffer and, if the attacker may control the contents of memory immediately following inputbuf, can leave the application susceptible to a buffer overflow attack.

Example 2: In the following code, readlink() expands the name of a symbolic link stored in the buffer path so that the buffer buf contains the absolute path of the file referenced by the symbolic link. The length of the resulting value is then calculated using strlen().


...
char buf[MAXPATH];
...
readlink(path, buf, MAXPATH);
int length = strlen(buf);
...


The code in Example 2 will not behave correctly because the value read into buf by readlink() will not be null-terminated. In testing, vulnerabilities such as this one might not be caught because the unused contents of buf and the memory immediately following it may be null, thereby causing strlen() to appear as if it is behaving correctly. However, in the wild strlen() will continue traversing memory until it encounters an arbitrary null character on the stack, which results in a value of length that is much larger than the size of buf and may cause a buffer overflow in subsequent uses of this value.

Example 3: The following code uses snprintf() to copy a user input string and place it in multiple output strings. Despite providing additional guardrails compared to sprintf(), notably the specification of a maximum output size, the snprintf() function is still susceptible to a string termination error when the specified output size is larger than the prospective input. String termination errors can lead to downstream problems such as a memory leak or buffer overflow.


...
char no_null_term[5] = getUserInput();

char output_1[20];
snprintf(output_1, 20, "%s", no_null_term);

char output_2[20];
snprintf(output_2, 20, "%s", no_null_term);


printf("%s\n", output_1);
printf("%s\n", output_2);
...


The code in Example 3 demonstrates a memory leak. When output_2 is populated with no_null_term, snprintf() must read from the location of no_null_term until a null character is encountered or the specified size limit is reached. Because there is no termination in no_null_term, snprintf continues to read into the data of output_1 where it eventually reaches a null terminating character provided by the first call of snprintf(). The memory leak is demonstrated by the printf() of output_2, which contains the character sequence of no_null_term twice.

Traditionally, strings are represented as a region of memory containing data terminated with a null character. Older string-handling methods frequently rely on this null character to determine the length of the string. If a buffer that does not contain a null-terminator is passed to one of these functions, the function will read past the end of the buffer.

Malicious users typically exploit this type of vulnerability by injecting data with unexpected size or content into the application. They may provide the malicious input either directly as input to the program or indirectly by modifying application resources, such as configuration files. In the event that an attacker causes the application to read beyond the bounds of a buffer, the attacker may be able to use a resulting buffer overflow to inject and execute arbitrary code on the system.
References
[1] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[2] Standards Mapping - Common Weakness Enumeration CWE ID 170, CWE ID 665
[3] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754, CCI-002824
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[7] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3, Rule 21.17
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1), SI-16 Memory Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation, SI-16 Memory Protection
[12] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[14] Standards Mapping - OWASP Top 10 2004 A5 Buffer Overflow
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.5
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.2
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[27] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 665
[28] Standards Mapping - SANS Top 25 2010 Risky Resource Management - CWE ID 665
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3590.1 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3590.1 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3590.1 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3590.1 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3590.1 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3590.1 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3590.1 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I, APSC-DV-002590 CAT I
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Buffer Overflow (WASC-07)
[53] Standards Mapping - Web Application Security Consortium 24 + 2 Buffer Overflow
desc.dataflow.cpp.string_termination_error.master
Abstract
Stream ciphers are dangerous to use when encrypted data is stored on disk, or if the key is used more than once.
Explanation
Stream ciphers are vulnerable to "key re-use" attacks, also called "two-time pad" attacks. This type of vulnerability occurs when you use the same key more than once because it is trivial to XOR the two ciphertext strings and nullify the key, which leaves only XOR'ed plain text. Due to the way human language is formatted, it is usually trivial to recover to the original two messages.
To stop the aforementioned attacks requires the use of a fresh initialization vector (IV), and therefore stream ciphers are not suitable to store encrypted data, as it means that either:
1) The disk sector is used as the IV:
This is insecure as it requires re-using the same IV every time the stored data requires modification.
2) Using a complicated system to map fresh IVs to disk sectors:
This is difficult to maintain. Such an approach requires that IVs are continuously updated, need to be unreadable by users, and requires that the ciphertext consumes more disk space than the unencrypted plain text.

Based on these two points, it is disadvantageous to use stream ciphers instead of block ciphers to store encrypted data. Another problem with stream ciphers is that they provide no authentication and therefore are vulnerable to "bit-flipping" attacks. Some block ciphers such as "CTR" are vulnerable to these same attacks because they function similarly to stream ciphers.

Example 1: The following code creates a stream cipher that is used to encrypt data with a constant IV and store it on disk:


import (
"crypto/aes"
"crypto/cipher"
"os"
)
...
iv = b'1234567890123456'
CTRstream = cipher.NewCTR(block, iv)
CTRstream.XORKeyStream(plaintext, ciphertext)
...
f := os.Create("data.enc")
f.Write(ciphertext)
f.Close()


In Example 1, because iv is set as a constant initialization vector, this is susceptible to re-use attacks.
References
[1] Disk Encryption Theory Wikipedia
[2] Clemens Fruhwirth New Methods in Hard Disk Encryption
[3] Standards Mapping - Common Weakness Enumeration CWE ID 327
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[5] Standards Mapping - FIPS200 MP
[6] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-10 Non-Repudiation (P2), SC-13 Cryptographic Protection (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-10 Non-Repudiation, SC-13 Cryptographic Protection
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.9.3 Cryptographic Software and Devices Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.2.2 Algorithms (L2 L3), 8.3.7 Sensitive Private Data (L2 L3), 9.1.2 Communications Security Requirements (L1 L2 L3), 9.1.3 Communications Security Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[11] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[13] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[14] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[15] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[17] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.1 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 327
[32] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 327
[33] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 327
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
desc.semantic.golang.weak_encryption_stream_cipher
Abstract
Stream ciphers are dangerous to use with stored data or if the key is used more than once.
Explanation
Stream ciphers are vulnerable to "key re-use" attacks, also called "two-time pad" attacks. This means that if the same key is used more than once, it is trivial to XOR the two strings of ciphertext and nullify the key, leaving only the XOR'ed plain text. Due to the way human language is formatted, it is usually trivial to get back to the original two messages.
As there is a requirement to use a fresh initialization vector (IV) to stop the aforementioned attacks, stream ciphers are not suitable for storing encrypted data, as it would mean either:
1) using the disk sector as the IV:
This is insecure because you must reuse the same IV every time the stored data needs to be modified.
2) have a complicated system that maps fresh IVs to disk sectors:
This is difficult to maintain, because it requires continuous updates, must not be user-readable, and requires the ciphertext to consume much more disk space than the unencrypted plain text alone.

These two points make it disadvantageous to use stream ciphers instead of block ciphers to store encrypted data. Another problem with stream ciphers is that they provide no authentication and thus are vulnerable to "bit-flipping" attacks. Some block ciphers such as "CTR" are vulnerable to these same attacks because they perform similarly to stream ciphers.

Example 1: The following code creates a stream cipher that is then used to encrypt data with a constant IV and store it on disk:


...
const cipher = crypto.createCipheriv("AES-256-CTR", key, 'iv')
const ciphertext = cipher.update(plaintext, 'utf8');
cipher.final();
fs.writeFile('my_encrypted_data', ciphertext, function (err) {
...
});
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 327
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[3] Standards Mapping - FIPS200 MP
[4] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-10 Non-Repudiation (P2), SC-13 Cryptographic Protection (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-10 Non-Repudiation, SC-13 Cryptographic Protection
[7] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.9.3 Cryptographic Software and Devices Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.2.2 Algorithms (L2 L3), 8.3.7 Sensitive Private Data (L2 L3), 9.1.2 Communications Security Requirements (L1 L2 L3), 9.1.3 Communications Security Requirements (L1 L2 L3)
[8] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[9] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[11] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[12] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[13] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[14] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[15] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[16] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.1 - Use of Cryptography
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[29] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 327
[30] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 327
[31] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 327
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
desc.structural.javascript.weak_encryption_stream_cipher
Abstract
Stream ciphers are dangerous to use when encrypted data is going to be stored on disk, or if the key is used more than once.
Explanation
Stream ciphers are vulnerable to "key re-use" attacks, also called "two-time pad" attacks. This means that if the same key is used more than once, it is trivial to XOR the two strings of ciphertext and nullify the key, leaving only the XOR'ed plain text. Due to the way human language is formatted, it is usually trivial to get back to the original two messages.
As there is a requirement to use a fresh initialization vector (IV) to stop the aforementioned attacks, stream ciphers are not suitable for storing encrypted data, as it would mean either:
1) using the disk sector as the IV:
This is insecure because you must reuse the same IV every time the stored data needs to be modified.
2) have a complicated system that maps fresh IVs to disk sectors:
This is difficult to maintain, because it requires continuous updates, must not be user-readable, and requires the ciphertext to consume much more disk space than the unencrypted plain text alone.

These two points make it disadvantageous to use stream ciphers instead of block ciphers to store encrypted data. Another problem with stream ciphers is that they provide no authentication and thus are vulnerable to "bit-flipping" attacks. Some block ciphers such as "CTR" are vulnerable to these same attacks because they perform similarly to stream ciphers.

Example 1: The following code creates a stream cipher that is then used to encrypt data with a constant IV and store it on disk:


from Crypto.Cipher import AES
from Crypto import Random
...
key = Random.new().read(AES.block_size)
iv = b'1234567890123456'
cipher = AES.new(key, AES.MODE_CTR, iv, counter)
...
encrypted = cipher.encrypt(data)
f = open("data.enc", "wb")
f.write(encrypted)
f.close()
...


In Example 1, since iv is set as a constant initialization vector, this will be susceptible to re-use attacks.
References
[1] Disk Encryption Theory Wikipedia
[2] Clemens Fruhwirth New Methods in Hard Disk Encryption
[3] Standards Mapping - Common Weakness Enumeration CWE ID 327
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[5] Standards Mapping - FIPS200 MP
[6] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-10 Non-Repudiation (P2), SC-13 Cryptographic Protection (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-10 Non-Repudiation, SC-13 Cryptographic Protection
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.9.3 Cryptographic Software and Devices Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.2.2 Algorithms (L2 L3), 8.3.7 Sensitive Private Data (L2 L3), 9.1.2 Communications Security Requirements (L1 L2 L3), 9.1.3 Communications Security Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[11] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[13] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[14] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[15] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[17] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.1 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 327
[32] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 327
[33] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 327
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
desc.semantic.python.weak_encryption_stream_cipher
Abstract
Stream ciphers are dangerous to use with stored data, or if the key is used more than once.
Explanation
Stream ciphers are vulnerable to "key re-use" attacks, also called "two-time pad" attacks. This means that if the same key is used more than once, it is trivial to XOR the two strings of ciphertext and nullify the key, leaving only the XOR'ed plain text. Due to the way human language is formatted, it is usually trivial to get back to the original two messages.
As there is a requirement to use a fresh initialization vector (IV) to stop the aforementioned attacks, stream ciphers are not suitable for storing encrypted data, as it would mean either:
1) using the disk sector as the IV:
This is insecure because you must reuse the same IV every time the stored data needs to be modified.
2) have a complicated system that maps fresh IVs to disk sectors:
This is difficult to maintain, because it requires continuous updates, must not be user-readable, and requires the ciphertext to consume much more disk space than the unencrypted plain text alone.

These two points make it disadvantageous to use stream ciphers instead of block ciphers to store encrypted data. Another problem with stream ciphers is that they provide no authentication and thus are vulnerable to "bit-flipping" attacks. Some block ciphers such as "CTR" are vulnerable to these same attacks because they perform similarly to stream ciphers.

Example 1: The following code creates a stream cipher that is then used to encrypt data with a constant IV and store it on disk:


require 'openssl'
...
cipher = OpenSSL::Cipher.new('AES-256-CTR')
cipher.encrypt
cipher.iv='iv'
...
encrypted = cipher.update(data) + cipher.final
File.open('my_encrypted_data', 'w') do |file|
file.write(encrypted)
end


In Example 1, since OpenSSL::Cipher#iv= is set as a constant initialization vector, this will be susceptible to re-use attacks.
References
[1] Disk Encryption Theory Wikipedia
[2] Clemens Fruhwirth New Methods in Hard Disk Encryption
[3] Standards Mapping - Common Weakness Enumeration CWE ID 327
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002450
[5] Standards Mapping - FIPS200 MP
[6] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-10 Non-Repudiation (P2), SC-13 Cryptographic Protection (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-10 Non-Repudiation, SC-13 Cryptographic Protection
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.9.3 Cryptographic Software and Devices Verifier Requirements (L2 L3), 6.2.1 Algorithms (L1 L2 L3), 6.2.2 Algorithms (L2 L3), 8.3.7 Sensitive Private Data (L2 L3), 9.1.2 Communications Security Requirements (L1 L2 L3), 9.1.3 Communications Security Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M6 Broken Cryptography
[11] Standards Mapping - OWASP Mobile 2024 M10 Insufficient Cryptography
[12] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CRYPTO-1
[13] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[14] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[15] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[16] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[17] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[18] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.3
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.3
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.1 - Use of Cryptography
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[31] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 327
[32] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 327
[33] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 327
[34] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3150.1 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3150.1 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3150.1 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3150.1 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3150.1 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3150.1 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3150.1 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000590 CAT II, APSC-DV-002010 CAT II, APSC-DV-002040 CAT II
desc.structural.ruby.weak_encryption_stream_cipher
Abstract
Including unvalidated data in an SMTP header can enable attackers to add arbitrary headers, such as CC or BCC that they can use to leak the mail contents to themselves or use the mail server as a spam bot.
Explanation
SMTP Header Manipulation vulnerabilities occur when:

1. Data enters an application through an untrusted source, most frequently an HTTP request in a web application.

2. The data is included in an SMTP header sent to a mail server without validation.

As with many software security vulnerabilities, SMTP Header Manipulation is a means to an end, not an end in itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an SMTP header.

One of the most common SMTP Header Manipulation attacks is to distribute spam emails. If an application contains a vulnerable "Contact us" form that allows setting the subject and the body of the email, an attacker can set any arbitrary content and inject a CC header with a list of email addresses to spam anonymously because the email is sent from the victim's server.

Example 1: The following code segment reads the subject and body of a "Contact us" form:


func handler(w http.ResponseWriter, r *http.Request) {
subject := r.FormValue("subject")
body := r.FormValue("body")
auth := smtp.PlainAuth("identity", "user@example.com", "password", "mail.example.com")
to := []string{"recipient@example.net"}
msg := []byte("To: " + recipient1 + "\r\n" + subject + "\r\n" + body + "\r\n")
err := smtp.SendMail("mail.example.com:25", auth, "sender@example.org", to, msg)
if err != nil {
log.Fatal(err)
}
}


Assuming a string consisting of standard alphanumeric characters, such as "Page not working" is submitted in the request, the SMTP headers might take the following form:


...
subject: [Contact us query] Page not working
...


However, because the value of the header is constructed from unvalidated user input the response only maintains this form if the value submitted for subject does not contain any CR and LF characters. If an attacker submits a malicious string, such as "Congratulations!! You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", then the SMTP headers would be of the following form:


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...


This effectively enables an attacker to craft spam messages or to send anonymous emails amongst other attacks.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 93
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[8] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[10] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[11] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2010 A1 Injection
[13] Standards Mapping - OWASP Top 10 2013 A1 Injection
[14] Standards Mapping - OWASP Top 10 2017 A1 Injection
[15] Standards Mapping - OWASP Top 10 2021 A03 Injection
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.golang.header_manipulation_smtp
Abstract
Including unvalidated data in an SMTP header can enable attackers to add arbitrary headers, such as CC or BCC that they can use to leak the mail contents to themselves or use the mail server as a spam bot.
Explanation
SMTP Header Manipulation vulnerabilities occur when:

1. Data enters an application through an untrusted source, most frequently an HTTP request in a web application.

2. The data is included in an SMTP header sent to a mail server without being validated.

As with many software security vulnerabilities, SMTP Header Manipulation is a means to an end, not an end in itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an SMTP header.

One of the most common SMTP Header Manipulation attacks is used for distributing spam emails. If an application contains a vulnerable "Contact us" form that allows setting the subject and the body of the email, an attacker will be able to set any arbitrary content and inject a CC header with a list of email addresses to spam anonymously since the email will be sent from the victim server.

Example 1: The following code segment reads the subject and body of a "Contact us" form:


String subject = request.getParameter("subject");
String body = request.getParameter("body");
MimeMessage message = new MimeMessage(session);
message.setFrom(new InternetAddress("webform@acme.com"));
message.setRecipients(Message.RecipientType.TO, InternetAddress.parse("support@acme.com"));
message.setSubject("[Contact us query] " + subject);
message.setText(body);
Transport.send(message);


Assuming a string consisting of standard alphanumeric characters, such as "Page not working" is submitted in the request, the SMTP headers might take the following form:


...
subject: [Contact us query] Page not working
...


However, because the value of the header is constructed from unvalidated user input the response will only maintain this form if the value submitted for subject does not contain any CR and LF characters. If an attacker submits a malicious string, such as "Congratulations!! You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", then the SMTP headers would be of the following form:


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...


This will effectively allow an attacker to craft spam messages or to send anonymous emails amongst other attacks.
References
[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers
[3] Standards Mapping - Common Weakness Enumeration CWE ID 93
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.java.header_manipulation_smtp
Abstract
Including unvalidated data in an SMTP header can enable attackers to add arbitrary headers, such as CC or BCC that they can use to leak the mail contents to themselves or use the mail server as a spam bot.
Explanation
SMTP Header Manipulation vulnerabilities occur when:

1. Data enters an application through an untrusted source, most frequently an HTTP request in a web application.

2. The data is included in an SMTP header sent to a mail server without being validated.

As with many software security vulnerabilities, SMTP Header Manipulation is a means to an end, not an end in itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an SMTP header.

One of the most common SMTP Header Manipulation attacks is for the use of distributing spam emails. If an application contains a vulnerable "Contact us" form that allows setting the subject and the body of the email, an attacker will be able to set any arbitrary content and inject a CC header with a list of email addresses to spam anonymously since the email will be sent from the victim server.

Example 1: The following code segment reads the subject and body of a "Contact us" form:


$subject = $_GET['subject'];
$body = $_GET['body'];
mail("support@acme.com", "[Contact us query] " . $subject, $body);


Assuming a string consisting of standard alphanumeric characters, such as "Page not working" is submitted in the request, the SMTP headers might take the following form:


...
subject: [Contact us query] Page not working
...


However, because the value of the header is constructed from unvalidated user input the response will only maintain this form if the value submitted for subject does not contain any CR and LF characters. If an attacker submits a malicious string, such as "Congratulations!! You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", then the SMTP headers would be of the following form:


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...


This will effectively allow an attacker to craft spam messages or to send anonymous emails amongst other attacks.
References
[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers
[3] Standards Mapping - Common Weakness Enumeration CWE ID 93
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.php.header_manipulation_smtp
Abstract
Including unvalidated data in an SMTP header can enable attackers to add arbitrary headers, such as CC or BCC that they can use to leak the mail contents to themselves or use the mail server as a spam bot.
Explanation
SMTP Header Manipulation vulnerabilities occur when:

1. Data enters an application through an untrusted source, most frequently an HTTP request in a web application.

2. The data is included in an SMTP header sent to a mail server without being validated.

As with many software security vulnerabilities, SMTP Header Manipulation is a means to an end, not an end in itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an SMTP header.

One of the most common SMTP Header Manipulation attacks is for the use of distributing spam emails. If an application contains a vulnerable "Contact us" form that allows setting the subject and the body of the email, an attacker will be able to set any arbitrary content and inject a CC header with a list of email addresses to spam anonymously since the email will be sent from the victim server.

Example 1: The following code segment reads the subject and body of a "Contact us" form:


body = request.GET['body']
subject = request.GET['subject']
session = smtplib.SMTP(smtp_server, smtp_tls_port)
session.ehlo()
session.starttls()
session.login(username, password)
headers = "\r\n".join(["from: webform@acme.com",
"subject: [Contact us query] " + subject,
"to: support@acme.com",
"mime-version: 1.0",
"content-type: text/html"])
content = headers + "\r\n\r\n" + body
session.sendmail("webform@acme.com", "support@acme.com", content)


Assuming a string consisting of standard alphanumeric characters, such as "Page not working" is submitted in the request, the SMTP headers might take the following form:


...
subject: [Contact us query] Page not working
...


However, because the value of the header is constructed from unvalidated user input the response will only maintain this form if the value submitted for subject does not contain any CR and LF characters. If an attacker submits a malicious string, such as "Congratulations!! You won the lottery!!!\r\ncc:victim1@mail.com,victim2@mail.com ...", then the SMTP headers would be of the following form:


...
subject: [Contact us query] Congratulations!! You won the lottery
cc: victim1@mail.com,victim2@mail.com
...


This will effectively allow an attacker to craft spam messages or to send anonymous emails amongst other attacks.
References
[1] OWASP Testing for IMAP/SMTP Injection (OTG-INPVAL-011)
[2] Vicente Aguilera Díaz MX Injection: Capturing and Exploiting Hidden Mail Servers
[3] Standards Mapping - Common Weakness Enumeration CWE ID 93
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[9] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.dataflow.python.header_manipulation_smtp
Abstract
Allowing unvalidated user input to specify the path of a file included in the page can allow attackers to inject malicious code or view sensitive files on the server.
Explanation
Unauthorized include vulnerabilities occur when:

1. Data enters a web application through an untrusted source, most frequently a web request.

2. The data is part of the string specifying the template attribute of a <cfinclude> tag.
Example 1: The following code uses input from a web form to construct the path to a special file used to format the user's homepage. The programmer has not considered the possibility that an attacker may provide a malicious filename, such as "../../users/wileyh/malicious", which will cause the application to include and execute the contents of a file in the attacker's home directory.


<cfinclude template =
"C:\\custom\\templates\\#Form.username#.cfm">


If an attacker is allowed to specify the file included by the <cfinclude> tag, they may be able to cause the application to include the contents of nearly any file in the server's file system in the current page. This ability can be leveraged in at least two significant ways. If an attacker can write to a location on the server's file system, such as the user's home directory or a common upload directory, then they may be able to cause the application to include a maliciously crafted file in the page, which will be executed by the server. Even without write access to the server's file system, an attacker may often gain access to sensitive or private information by specifying the path of a file on the server.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 94
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [18] CWE ID 094
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [17] CWE ID 094
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [11] CWE ID 094
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167
[6] Standards Mapping - FIPS200 SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[8] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2), SI-10 Information Input Validation (P1)
[9] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code, SI-10 Information Input Validation
[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.5 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.8 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[11] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[12] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[14] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[16] Standards Mapping - OWASP Top 10 2010 A1 Injection
[17] Standards Mapping - OWASP Top 10 2013 A1 Injection
[18] Standards Mapping - OWASP Top 10 2017 A1 Injection
[19] Standards Mapping - OWASP Top 10 2021 A03 Injection
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 6.5.3
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[32] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 094
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3600 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3600 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3600 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3600 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3600 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3600 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3600 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-003300 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-003300 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-003300 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-003300 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-003300 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-003300 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-003300 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-003300 CAT II
[56] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.cfml.unauthorized_include
Abstract
Sending unvalidated data to a web browser can result in the browser executing malicious code.
Explanation
Cross-site scripting (XSS) vulnerabilities occur when:

1. Data enters a web application through an untrusted source. In the case of DOM-based Artificial Intelegence (AI) XSS, data from an AI prompt response is written back into the page with client-side code. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.


2. The data is included in dynamic content that is sent to a web user without validation. In the case of DOM-based XSS, malicious content is executed as part of DOM (Document Object Model) creation, whenever the victim's browser parses the HTML page.

The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash, or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.

Example 1: The following JavaScript code segment retrieves a response from a large language model (LLM) and displays it to the user.


<SCRIPT>
var response = llm.invoke(user_prompt);
...
document.write(response);
</SCRIPT>


DOM-based XSS occurs when an attacker can modify a browser's DOM so that client-side code will be executed in an unintended, and potentially dangerous, manner.

The output of an LLM is unpredictable, enabling an attacker utilizing prompt engineering techniques to produce unexpected outputs and bypass developer instructions intended to prevent the LLM from producing dangerous responses.

As the example demonstrates, XSS vulnerabilities are caused by code that includes unvalidated responses from an LLM. There are three vectors by which an XSS attack can reach a victim:

- Data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.

- The application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker can perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.

- A source outside the application produces potentially dangrous data, such as an LLM, stores dangerous data in a database, or retrieves data from another data store. This dangerous data is subsequently read back into the application as trusted data and included in dynamic content.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [1] CWE ID 079
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[17] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[18] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[19] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[37] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[38] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[63] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.javascript.cross_site_scripting_dom_ai
Abstract
Sending unvalidated data to a web browser can result in the browser executing malicious code. Settings in the configuration can minimize and reduce the exposure to cross-site scripting
Explanation
Cross-site scripting (XSS) vulnerabilities occur when:

1. Data enters a web application through an untrusted source, most frequently a web request or database.

2. The data is included in dynamic content that is sent to a web user without validation.

The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.

Since attacks against XSS vulnerabilities often involve communicating with or redirecting to a malicious site controlled by the attacker, the ability to inject references to content on other domains is integral to many exploits. AntiSamy can be configured to prevent links to external domains, which diminishes the damage an attacker may cause through an XSS attack. However, this protection is only a partial solution and does not address the overall threat posed by XSS vulnerabilities.

Example 1: The following AntiSamy configuration entry allows links to URLs outside of the domain on which the application is running.

<attribute name="href" onInvalid="filterTag">
<regexp-list>
<regexp name="onsiteURL"/>
<regexp name="offsiteURL"/>
</regexp-list>
</attribute>
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 82, CWE ID 83, CWE ID 87, CWE ID 692
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [1] CWE ID 079
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001167, CCI-001310
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-18 Mobile Code (P2), SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-18 Mobile Code, SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[17] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[18] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[19] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[37] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[38] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-003300 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-003300 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-003300 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-003300 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-003300 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-003300 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-003300 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-003300 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-003300 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-003300 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-003300 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-003300 CAT II
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-003300 CAT II
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-003300 CAT II
[60] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-003300 CAT II
[61] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-003300 CAT II
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[63] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.config.java.xss_external_links
Abstract
Sending unvalidated data to a web browser can result in the browser executing malicious code.
Explanation
Cross-site scripting (XSS) vulnerabilities occur when:

1. Data enters a web application through an untrusted source. Using Handlebars, you can create custom helpers that can be used to modify templates.


2. The data is included in dynamic content that is inserted into a template before being rendered without validation. In the case of a Handlebars helper, malicious content is rendered as the output of the template.

The malicious content in a Handlebars helper takes the form of a JavaScript segment, or any other type of code that the browser executes. As the output from a Handlebars template is typically HTML content to be passed to the browser, any potentially malicious content should be treated as unsafe and validated.

Example 1: Consider the following Handlebars helper code:


Handlebars.registerHelper('bolden', function (aString) {
return new Handlebars.SafeString("" + aString + "")
})
// ...
let template = Handlebars.compile('{{bolden someArgument}}')
myElem.innerHTML = template({someArgument: userInput})


The bolden helper is passed the user-controlled data userInput. Although the use of double curly braces ({{ and }}) typically means that the output will be HTML-encoded, in this scenario the bolden helper overrides any validation by passing the input into new Handlebars.SafeString(), leading to the input being rendered as regular HTML. When the HTML returns from template() it is passed into the innerHTML property leading to a DOM-based XSS.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [1] CWE ID 079
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[17] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[18] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[19] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[37] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[38] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[39] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[63] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.javascript.cross_site_scripting_handlebars_helper
Abstract
Sending unvalidated data to a web browser can result in the browser executing malicious code.
Explanation
Cross-site scripting (XSS) vulnerabilities occur when:

1. Data enters a web application through an untrusted source. In SAPUI5, you can create custom controls by extending others. Because these controls are intended for generic use, the developer should expect that user-controlled data is passed to one of its attributes.


2. The data is included in dynamic content that is sent to a web user without validation. In the case of an SAPUI5 control, malicious content is rendered as part of the control.

The malicious content in an SAPUI5 control takes the form of a JavaScript segment, or any other type of code that the browser executes. As SAPUI5 controls are supposed to be generically re-used over and over, an instance of an application might not directly pass malicious data to the control, but this should be treated the same as a standard DOM-based XSS weakness. A trivial change to the application code could lead to malicious information being passed. The only exception is when the control dynamically generates HTML unsafely, such as the sap.ui.core.HTML control's content property.

Example 1: Consider the custom control:


sap.ui.define([
'sap/ui/core/Control'
], function (Control) {
return Control.extend('CustomControl', {
metadata: {
properties: {
foo: { type: 'string', defaultValue: '' }
}
},
renderer: {
render: function (oRm, oControl) {
oRm.write('<div>' + oControl.getId() + ':' + oControl.getFoo() + '</div>')
}
},
init: function () { }
})
})


The foo attribute may be passed user-controlled data from another part of the application which would be rendered directly to the DOM.

This code example operates correctly if the information passed to the attribute foo contains only standard alphanumeric text. If foo has a value that includes metacharacters or source code, then when this control is rendered, the code is added to the DOM for the browser to execute.
References
[1] Understanding Malicious Content Mitigation for Web Developers CERT
[2] HTML 4.01 Specification W3
[3] Cross-Site Scripting in SAPUI5-based Web Applications SAP
[4] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[10] Standards Mapping - Common Weakness Enumeration Top 25 2024 [1] CWE ID 079
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[12] Standards Mapping - FIPS200 SI
[13] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[16] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[17] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[18] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[19] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[20] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[22] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[23] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[24] Standards Mapping - OWASP Top 10 2021 A03 Injection
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[37] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[38] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[39] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[40] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[63] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[64] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.javascript.cross_site_scripting_sapui5_control
Abstract
Allowing user input to control settings which determine Same-Origin Policy (SOP) can create XSS vulnerabilities.
Explanation
Cross-site scripting (XSS) vulnerabilities through Same-Origin Policy (SOP) bypasses occur when:

1. Data enters a web application through an untrusted source.


2. The data is passed to a setting that determines the origin of the page where scripts can run, such as document.domain.

Once this is performed, this enables an attacker on another domain to set document.domain the same, and execute scripts on the page, as if in they are located on the exact same domain.

Example 1: The following takes a URL parameter domain and passes it as the domain for the page's Same-Origin Policy (SOP).


<SCRIPT>
var pos = document.URL.indexOf("domain=")+7;
document.domain = document.URL.substring(pos,document.URL.length);
</SCRIPT>


Most browsers will only allow a valid superdomain to be passed to document.domain, therefore if the page is located at "http://www.example.com", then document.domain can be set to "www.example.com", or "example.com". It cannot be set to "com" or "example.org".
However, if an attacker is on another part of the website which they can control, they may be able to execute scripts on part of the site that they do not have control over.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 79, CWE ID 80
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [2] CWE ID 079
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [1] CWE ID 079
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [2] CWE ID 079
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [2] CWE ID 079
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [2] CWE ID 079
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [1] CWE ID 079
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[9] Standards Mapping - FIPS200 SI
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.3 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[14] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[15] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[16] Standards Mapping - OWASP Top 10 2004 A4 Cross Site Scripting
[17] Standards Mapping - OWASP Top 10 2007 A1 Cross Site Scripting (XSS)
[18] Standards Mapping - OWASP Top 10 2010 A2 Cross-Site Scripting (XSS)
[19] Standards Mapping - OWASP Top 10 2013 A3 Cross-Site Scripting (XSS)
[20] Standards Mapping - OWASP Top 10 2017 A7 Cross-Site Scripting (XSS)
[21] Standards Mapping - OWASP Top 10 2021 A03 Injection
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.7
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.7
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.7
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.7
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.7
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 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, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 079
[35] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 079
[36] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 079
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3580 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3580 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3580 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3580 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3580 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3580 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3580 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002490 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002490 CAT I, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Scripting (WASC-08)
[61] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Scripting
desc.dataflow.javascript.cross_site_scripting_SOP_bypass
Abstract
Allowing unvalidated user-input to influence the run-time environment of dynamically executed code can allow attackers to execute malicious code.
Explanation
Many modern programming languages allow dynamic interpretation of source instructions. This capability allows programmers to execute dynamic operations based on input received from the user. Code manipulation vulnerabilities occur when the programmer allows some user supplied data to alter an aspect of run-time environment of dynamically executed code. Without proper validation, a user might specify operations the programmer does not intend.

Example 1: In this example, the application retrieves the script execution scope from the web application.


...
ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
ScriptEngine scriptEngine = scriptEngineManager.getEngineByExtension("js");
ScriptContext newContext = new SimpleScriptContext();
Bindings engineScope = newContext.getBindings(request.getParameter("userName"));

userOps = request.getParameter("operation");
Object result = scriptEngine.eval(userOps,newContext);
...


The program behaves correctly when the page_scope parameter is the expected username. However, if an attacker specifies the value for GLOBAL_SCOPE, the operations will have access to all attributes within all engines created by the same ScriptEngine.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 94, CWE ID 494
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [18] CWE ID 094
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [17] CWE ID 094
[4] Standards Mapping - Common Weakness Enumeration Top 25 2022 [25] CWE ID 094
[5] Standards Mapping - Common Weakness Enumeration Top 25 2023 [23] CWE ID 094
[6] Standards Mapping - Common Weakness Enumeration Top 25 2024 [11] CWE ID 094
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001764, CCI-001774, CCI-002754
[8] Standards Mapping - FIPS200 SI
[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 CM-7 Least Functionality (P1), SI-10 Information Input Validation (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 CM-7 Least Functionality, SI-10 Information Input Validation
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.14.2 Configuration Architectural Requirements (L2 L3), 5.2.5 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.8 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.3 File Execution Requirements (L1 L2 L3), 14.2.3 Dependency (L1 L2 L3)
[13] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[14] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[30] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116, Risky Resource Management - CWE ID 094
[31] Standards Mapping - SANS Top 25 2010 Risky Resource Management - CWE ID 494
[32] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 494
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Process Validation (WASC-40), Improper Input Handling (WASC-20)
desc.dataflow.java.dynamic_code_evaluation_code_manipulation
Abstract
Interpreting user-controlled instructions at runtime can allow attackers to execute malicious code.
Explanation
Many modern programming languages allow dynamic interpretation of source instructions. This capability allows programmers to perform dynamic instructions based on input received from the user. Code injection vulnerabilities occur when the programmer incorrectly assumes that instructions supplied directly from the user will perform only innocent operations, such as performing simple calculations on active user objects or otherwise modifying the user's state. However, without proper validation, a user might specify operations the programmer does not intend.

Example 1: In this code injection example, a request parameter is bound into a razor template which is evaluated.


...
string name = Request["username"];
string template = "Hello @Model.Name! Welcome " + name + "!";
string result = Razor.Parse(template, new { Name = "World" });
...


The program behaves correctly when the operation parameter is a benign value, such as "John", in which case the result variable is assigned a value of "Hello World! Welcome John!". However, if an attacker specifies languages operations that are both valid and malicious, those operations would be executed with the full privilege of the parent process. Such attacks are even more dangerous when the underlying language provides access to system resources or allows execution of system commands. For example, Razor allows invocation of C# objects; if an attacker were to specify " @{ System.Diagnostics.Process proc = new System.Diagnostics.Process(); proc.EnableRaisingEvents=false; proc.StartInfo.FileName=\"calc\"; proc.Start(); }" as the value of name, a system command would be executed on the host system.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 95, CWE ID 494
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [18] CWE ID 094
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [17] CWE ID 094
[4] Standards Mapping - Common Weakness Enumeration Top 25 2022 [25] CWE ID 094
[5] Standards Mapping - Common Weakness Enumeration Top 25 2023 [23] CWE ID 094
[6] Standards Mapping - Common Weakness Enumeration Top 25 2024 [11] CWE ID 094
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001764, CCI-001774, CCI-002754
[8] Standards Mapping - FIPS200 SI
[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 CM-7 Least Functionality (P1), SI-10 Information Input Validation (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 CM-7 Least Functionality, SI-10 Information Input Validation
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.14.2 Configuration Architectural Requirements (L2 L3), 5.2.4 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.5 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.8 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.3 File Execution Requirements (L1 L2 L3), 14.2.3 Dependency (L1 L2 L3)
[13] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[14] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[16] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A03 Injection
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 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, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116, Risky Resource Management - CWE ID 094
[35] Standards Mapping - SANS Top 25 2010 Risky Resource Management - CWE ID 494
[36] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 494
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.dotnet.dynamic_code_evaluation_script_injection
Abstract
Interpreting user-controlled instructions at run-time can allow attackers to execute malicious code.
Explanation
Many modern programming languages allow dynamic interpretation of source instructions. This capability allows programmers to perform dynamic instructions based on input received from the user. Code injection vulnerabilities occur when the programmer incorrectly assumes that instructions supplied directly from the user will perform only innocent operations, such as performing simple calculations on active user objects or otherwise modifying the user's state. However, without proper validation, a user might specify operations the programmer does not intend.

Example 1: In this classic code injection example, the application implements a basic calculator that allows the user to specify commands for execution.


...
ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
ScriptEngine scriptEngine = scriptEngineManager.getEngineByExtension("js");
userOps = request.getParameter("operation");
Object result = scriptEngine.eval(userOps);
...


The program behaves correctly when the operation parameter is a benign value, such as "8 + 7 * 2", in which case the result variable is assigned a value of 22. However, if an attacker specifies languages operations that are both valid and malicious, those operations would be executed with the full privilege of the parent process. Such attacks are even more dangerous when the underlying language provides access to system resources or allows execution of system commands. For example, JavaScript allows invocation of Java objects; if an attacker were to specify " java.lang.Runtime.getRuntime().exec("shutdown -h now")" as the value of operation, a shutdown command would be executed on the host system.
References
[1] INJECT-8: Take care interpreting untrusted code Oracle
[2] Standards Mapping - Common Weakness Enumeration CWE ID 95, CWE ID 494
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [18] CWE ID 094
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [17] CWE ID 094
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [25] CWE ID 094
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [23] CWE ID 094
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [11] CWE ID 094
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001764, CCI-001774, CCI-002754
[9] Standards Mapping - FIPS200 SI
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 CM-7 Least Functionality (P1), SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 CM-7 Least Functionality, SI-10 Information Input Validation
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.14.2 Configuration Architectural Requirements (L2 L3), 5.2.4 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.5 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.8 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.3 File Execution Requirements (L1 L2 L3), 14.2.3 Dependency (L1 L2 L3)
[14] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[15] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[17] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[19] Standards Mapping - OWASP Top 10 2010 A1 Injection
[20] Standards Mapping - OWASP Top 10 2013 A1 Injection
[21] Standards Mapping - OWASP Top 10 2017 A1 Injection
[22] Standards Mapping - OWASP Top 10 2021 A03 Injection
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.3
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[35] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116, Risky Resource Management - CWE ID 094
[36] Standards Mapping - SANS Top 25 2010 Risky Resource Management - CWE ID 494
[37] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 494
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.dynamic_code_evaluation_script_injection
Abstract
Interpreting user-controlled instructions at runtime can allow attackers to execute malicious code.
Explanation
Many modern programming languages allow dynamic interpretation of source instructions. This capability allows programmers to perform dynamic instructions based on input received from the user. Code injection vulnerabilities occur when the programmer incorrectly assumes that instructions supplied directly from the user will perform only innocent operations, such as performing simple calculations on active user objects or otherwise modifying the user's state. However, without proper validation, a user might specify operations the programmer does not intend.

Example 1: In this classic code injection example, the application implements a basic calculator that allows the user to specify commands for execution.


...
userOp = form.operation.value;
calcResult = eval(userOp);
...


The program behaves correctly when the operation parameter is a benign value, such as "8 + 7 * 2", in which case the calcResult variable is assigned a value of 22. However, if an attacker specifies languages operations that are both valid and malicious, those operations would be executed with the full privilege of the parent process. Such attacks are even more dangerous when the underlying language provides access to system resources or allows execution of system commands. In the case of JavaScript, the attacker may utilize this vulnerability to perform a cross-site scripting attack.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 95, CWE ID 494
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [18] CWE ID 094
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [17] CWE ID 094
[4] Standards Mapping - Common Weakness Enumeration Top 25 2022 [25] CWE ID 094
[5] Standards Mapping - Common Weakness Enumeration Top 25 2023 [23] CWE ID 094
[6] Standards Mapping - Common Weakness Enumeration Top 25 2024 [11] CWE ID 094
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001764, CCI-001774, CCI-002754
[8] Standards Mapping - FIPS200 SI
[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 CM-7 Least Functionality (P1), SI-10 Information Input Validation (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 CM-7 Least Functionality, SI-10 Information Input Validation
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.14.2 Configuration Architectural Requirements (L2 L3), 5.2.4 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.5 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.8 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.3 File Execution Requirements (L1 L2 L3), 14.2.3 Dependency (L1 L2 L3)
[13] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[14] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[16] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A03 Injection
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 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, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116, Risky Resource Management - CWE ID 094
[35] Standards Mapping - SANS Top 25 2010 Risky Resource Management - CWE ID 494
[36] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 494
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.javascript.dynamic_code_evaluation_script_injection
Abstract
Executing arbitrary source instructions from an untrusted source can lead to malicious code execution.
Explanation
Many modern languages allow dynamic interpretation of source instructions. This ability can be used when the programmer needs to perform user supplied instructions on data but would rather utilize the underlying language constructs instead of implementing code to interpret the user input. The user supplied instructions are expected to be innocent operations such as small calculations on active user objects, modification of the state of user objects, etc. However, if a programmer is not careful, a user may specify operations outside of the programmer's intentions.

Example 1: A classic example application that may allow underlying programming constructs to be specified by the user is a calculator. The following ASP code accepts basic mathematical operations from the user to be computed and returned:


...
strUserOp = Request.Form('operation')
strResult = Eval(strUserOp)
...


The program's intended behavior holds in an example where the operation parameter is "8 + 7 * 2". The strResult variable returns with a value of 22. However, if a user were to specify other valid language operations, those operations would not only be executed but executed with the full privilege of the parent process. Arbitrary code execution becomes more dangerous when the underlying language provides access to system resources or allows execution of system commands. For example, if an attacker were to specify operation as " Shell('C:\WINDOWS\SYSTEM32\TSSHUTDN.EXE 0 /DELAY:0 /POWERDOWN')" a shutdown command would be executed on the host system.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 95, CWE ID 494
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [18] CWE ID 094
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [17] CWE ID 094
[4] Standards Mapping - Common Weakness Enumeration Top 25 2022 [25] CWE ID 094
[5] Standards Mapping - Common Weakness Enumeration Top 25 2023 [23] CWE ID 094
[6] Standards Mapping - Common Weakness Enumeration Top 25 2024 [11] CWE ID 094
[7] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001764, CCI-001774, CCI-002754
[8] Standards Mapping - FIPS200 SI
[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 CM-7 Least Functionality (P1), SI-10 Information Input Validation (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 CM-7 Least Functionality, SI-10 Information Input Validation
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.14.2 Configuration Architectural Requirements (L2 L3), 5.2.4 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.5 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.8 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.3 File Execution Requirements (L1 L2 L3), 14.2.3 Dependency (L1 L2 L3)
[13] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[14] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[15] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[16] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2007 A3 Malicious File Execution
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A03 Injection
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.3
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 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, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116, Risky Resource Management - CWE ID 094
[35] Standards Mapping - SANS Top 25 2010 Risky Resource Management - CWE ID 494
[36] Standards Mapping - SANS Top 25 2011 Risky Resource Management - CWE ID 494
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.vb.dynamic_code_evaluation_script_injection
Abstract
Deserializing user-controlled data at run-time can allow attackers to execute arbitrary code.
Explanation
Python Official documentation states that:


The pickle module is not intended to be secure against erroneous or maliciously constructed data. Never unpickle data received from an untrusted or unauthenticated source.


Pickle is a powerful serializing library that provides developers with an easy way to transmit objects, serializing them to a custom Pickle representation. Pickle allows arbitrary objects to declare how they should be deserialized by defining a __reduce__ method. This method should return a callable and the arguments for it. Pickle will call the callable with the provided arguments to construct the new object allowing the attacker to execute arbitrary commands.
References
[1] Python object serialization Python
[2] Python object serialization Python
[3] Python Library Reference Python
[4] Standards Mapping - Common Weakness Enumeration CWE ID 502
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [23] CWE ID 502
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [21] CWE ID 502
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [13] CWE ID 502
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [12] CWE ID 502
[9] Standards Mapping - Common Weakness Enumeration Top 25 2023 [15] CWE ID 502
[10] Standards Mapping - Common Weakness Enumeration Top 25 2024 [16] CWE ID 502
[11] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001764, CCI-001774, CCI-002754
[12] Standards Mapping - FIPS200 SI
[13] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[14] Standards Mapping - NIST Special Publication 800-53 Revision 4 CM-7 Least Functionality (P1), SI-10 Information Input Validation (P1)
[15] Standards Mapping - NIST Special Publication 800-53 Revision 5 CM-7 Least Functionality, SI-10 Information Input Validation
[16] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.5.2 Input and Output Architectural Requirements (L2 L3), 5.5.1 Deserialization Prevention Requirements (L1 L2 L3), 5.5.3 Deserialization Prevention Requirements (L1 L2 L3)
[17] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[18] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[19] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[21] Standards Mapping - OWASP Top 10 2010 A1 Injection
[22] Standards Mapping - OWASP Top 10 2013 A1 Injection
[23] Standards Mapping - OWASP Top 10 2017 A8 Insecure Deserialization
[24] Standards Mapping - OWASP Top 10 2021 A08 Software and Data Integrity Failures
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation, Control Objective C.3.5 - Web Software Attack Mitigation
[37] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[61] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.python.dynamic_code_evaluation_unsafe_pickle_deserialization
Abstract
Deserializing user-controlled XML documents at run-time can allow attackers to execute malicious arbitrary code on the server.
Explanation
The JDK XMLEncoder and XMLDecoder classes provide the developer with an easy way to persist objects, serializing them to XML documents. But XMLEncoder also allows a developer to serialize method calls and if an attacker can provide the XML document to be deserialized by XMLDecoder, he may be able to execute any arbitrary code on the server.

Example 1: The following Java code shows an instance of XMLDecoder processing untrusted input.


XMLDecoder decoder = new XMLDecoder(new InputSource(new InputStreamReader(request.getInputStream(), "UTF-8")));

Object object = decoder.readObject();
decoder.close();
Example 1: The following XML document will instantiate a ProcessBuilder object and will invoke its static start() method to run the windows calculator.


<java>
<object class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="1" >
<void index="0">
<string>c:\\windows\\system32\\calc.exe</string>
</void>
</array>
<void method="start"/>
</object>
</java>
References
[1] Oracle Oracle official documentation for XMLDecoder
[2] Standards Mapping - Common Weakness Enumeration CWE ID 502
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [23] CWE ID 502
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [21] CWE ID 502
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [13] CWE ID 502
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [12] CWE ID 502
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [15] CWE ID 502
[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [16] CWE ID 502
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-001764, CCI-001774, CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 CM-7 Least Functionality (P1), SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 CM-7 Least Functionality, SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.5.2 Input and Output Architectural Requirements (L2 L3), 5.5.1 Deserialization Prevention Requirements (L1 L2 L3), 5.5.3 Deserialization Prevention Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A8 Insecure Deserialization
[23] Standards Mapping - OWASP Top 10 2021 A08 Software and Data Integrity Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002550 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.dynamic_code_evaluation_xmldecoder_injection
Abstract
Populating password fields in an HTML form could result in a system compromise.
Explanation
Populating password fields in an HTML form allows anyone to see their values in the HTML source. Furthermore, sensitive information stored in password fields may be cached by proxies or browsers.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 259, CWE ID 798
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [19] CWE ID 798
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287, [20] CWE ID 798
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287, [16] CWE ID 798
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287, [15] CWE ID 798
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287, [18] CWE ID 798
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287, [22] CWE ID 798
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000196, CCI-000197, CCI-001199, CCI-002361, CCI-002367
[9] Standards Mapping - FIPS200 IA
[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-12 Session Termination (P2), IA-5 Authenticator Management (P1), SC-28 Protection of Information at Rest (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-12 Session Termination, IA-5 Authenticator Management, SC-28 Protection of Information at Rest
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.10.4 Service Authentication Requirements (L2 L3), 2.3.1 Authenticator Lifecycle Requirements (L1 L2 L3), 2.6.2 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.10.1 Service Authentication Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 2.10.4 Service Authentication Requirements (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.5.2 Token-based Session Management (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.4.1 Secret Management (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3), 10.2.3 Malicious Code Search (L3)
[14] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[15] Standards Mapping - OWASP Mobile 2024 M1 Improper Credential Usage
[16] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[17] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[18] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[19] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[20] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[21] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[22] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.2.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.2.1, Requirement 6.2.4, Requirement 6.5.3, Requirement 6.5.6, Requirement 8.3.2
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 6.1 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 6.1 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 6.1 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[35] Standards Mapping - SANS Top 25 2009 Porous Defenses - CWE ID 259
[36] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 798
[37] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 798
[38] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3210.1 CAT II, APP3340 CAT I, APP3350 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3210.1 CAT II, APP3340 CAT I, APP3350 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3210.1 CAT II, APP3340 CAT I, APP3350 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3210.1 CAT II, APP3340 CAT I, APP3350 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3210.1 CAT II, APP3340 CAT I, APP3350 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3210.1 CAT II, APP3340 CAT I, APP3350 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3210.1 CAT II, APP3340 CAT I, APP3350 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000060 CAT II, APSC-DV-001740 CAT I, APSC-DV-001750 CAT I, APSC-DV-002330 CAT II, APSC-DV-003110 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000060 CAT II, APSC-DV-001740 CAT I, APSC-DV-001750 CAT I, APSC-DV-002330 CAT II, APSC-DV-003110 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000060 CAT II, APSC-DV-001740 CAT I, APSC-DV-001750 CAT I, APSC-DV-002330 CAT II, APSC-DV-003110 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000060 CAT II, APSC-DV-001740 CAT I, APSC-DV-001750 CAT I, APSC-DV-002330 CAT II, APSC-DV-003110 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000060 CAT II, APSC-DV-001740 CAT I, APSC-DV-001750 CAT I, APSC-DV-002330 CAT II, APSC-DV-003110 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000060 CAT II, APSC-DV-001740 CAT I, APSC-DV-001750 CAT I, APSC-DV-002330 CAT II, APSC-DV-003110 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000060 CAT II, APSC-DV-001740 CAT I, APSC-DV-001750 CAT I, APSC-DV-002330 CAT II, APSC-DV-003110 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000060 CAT II, APSC-DV-001740 CAT I, APSC-DV-001750 CAT I, APSC-DV-002330 CAT II, APSC-DV-003110 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000060 CAT II, APSC-DV-001740 CAT I, APSC-DV-001750 CAT I, APSC-DV-002330 CAT II, APSC-DV-003110 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000060 CAT II, APSC-DV-001740 CAT I, APSC-DV-001750 CAT I, APSC-DV-002330 CAT II, APSC-DV-003110 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000060 CAT II, APSC-DV-001740 CAT I, APSC-DV-001750 CAT I, APSC-DV-002330 CAT II, APSC-DV-003110 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000060 CAT II, APSC-DV-001740 CAT I, APSC-DV-001750 CAT I, APSC-DV-002330 CAT II, APSC-DV-003110 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000060 CAT II, APSC-DV-001740 CAT I, APSC-DV-001750 CAT I, APSC-DV-002330 CAT II, APSC-DV-003110 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000060 CAT II, APSC-DV-001740 CAT I, APSC-DV-001750 CAT I, APSC-DV-002330 CAT II, APSC-DV-003110 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000060 CAT II, APSC-DV-001740 CAT I, APSC-DV-001750 CAT I, APSC-DV-002330 CAT II, APSC-DV-003110 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000060 CAT II, APSC-DV-001740 CAT I, APSC-DV-001750 CAT I, APSC-DV-002330 CAT II, APSC-DV-003110 CAT I
desc.content.html.password_management_password_in_html_form
Abstract
Processing an unvalidated XSL stylesheet can allow an attacker to change the structure and contents of the resultant XML, include arbitrary files from the file system, or execute arbitrary code.
Explanation
XSLT injection occurs when:

1. Data enters a program from an untrusted source.

2. The data is written to an XSL stylesheet.


Applications typically use XSL stylesheet to transform XML documents from one format to another. XSL stylesheets include special functions which enhance the transformation process but introduce additional vulnerabilities if used incorrectly.

The semantics of XSL stylesheets and processing can be altered if an attacker has the ability to write XSL elements in a stylesheet. An attacker could alter the output of a stylesheet such that an XSS (cross-site scripting) attack was enabled, expose the contents of local file system resources, or execute arbitrary code.

Example 1: Here is some code that is vulnerable to XSLT Injection:


...
String xmlUrl = Request["xmlurl"];
String xslUrl = Request["xslurl"];

XslCompiledTransform xslt = new XslCompiledTransform();
xslt.Load(xslUrl);

xslt.Transform(xmlUrl, "books.html");
...
Example 1 results in three different exploits when the attacker passes the identified XSL to the XSTL processor:

1. XSS:



<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<script>alert(123)</script>
</xsl:template>
</xsl:stylesheet>



When the XSL stylesheet is processed, the <script> tag is rendered to the victim's browser allowing a cross-site scripting attack to be performed.

2. Reading of arbitrary files on the server's file system:



<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<xsl:copy-of select="document('file:///c:/winnt/win.ini')"/>
</xsl:template>
</xsl:stylesheet>



The preceding XSL stylesheet will return the contents of the /etc/passwd file.

3. Execution of arbitrary code:

The XSLT processor has the ability to expose native language methods as XSLT functions if they are not disabled.



<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:App="http://www.tempuri.org/App">
<msxsl:script implements-prefix="App" language="C#">
<![CDATA[
public string ToShortDateString(string date)
{
System.Diagnostics.Process.Start("cmd.exe");
return "01/01/2001";
}
]]>
</msxsl:script>
<xsl:template match="ArrayOfTest">
<TABLE>
<xsl:for-each select="Test">
<TR>
<TD>
<xsl:value-of select="App:ToShortDateString(TestDate)" />
</TD>
</TR>
</xsl:for-each>
</TABLE>
</xsl:template>
</xsl:stylesheet>



The preceding stylesheet will execute the "cmd.exe" command on the server.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 494
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.14.2 Configuration Architectural Requirements (L2 L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.3 File Execution Requirements (L1 L2 L3), 14.2.3 Dependency (L1 L2 L3)
[8] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[11] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.dotnet.xslt_injection
Abstract
Processing an unvalidated XSL stylesheet can allow an attacker to change the structure and contents of the resultant XML, include arbitrary files from the file system, or execute arbitrary code.
Explanation
XSLT injection occurs when:

1. Data enters a program from an untrusted source.

2. The data is written to an XSL stylesheet.


Applications typically use XSL stylesheet to transform XML documents from one format to another. XSL stylesheets include special functions which enhance the transformation process but introduce additional vulnerabilities if used incorrectly.

The semantics of XSL stylesheets and processing can be altered if an attacker has the ability to write XSL elements in a stylesheet. An attacker could alter the output of a stylesheet such that an XSS (cross-site scripting) attack was enabled, expose the contents of local file system resources, or execute arbitrary code.

Example 1: Here is some code that is vulnerable to XSLT Injection:


...
InputStream xmlUrl = Utils.getFromURL(request.getParameter("xmlurl"));
InputStream xsltUrl = Utils.getFromURL(request.getParameter("xslurl"));

Source xmlSource = new StreamSource(xmlUrl);
Source xsltSource = new StreamSource(xsltUrl);
Result result = new StreamResult(System.out);

TransformerFactory transFact = TransformerFactory.newInstance();
Transformer trans = transFact.newTransformer(xsltSource);
trans.transform(xmlSource, result);
...


The code in Example 1 results in three different exploits when the attacker passes the identified XSL to the XSTL processor:

1. XSS:



<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<script>alert(123)</script>
</xsl:template>
</xsl:stylesheet>



When the XSL stylesheet is processed, the <script> tag is rendered to the victim's browser allowing a cross-site scripting attack to be performed.

2. Reading of arbitrary files on the server's file system:



<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<xsl:copy-of select="document('/etc/passwd')"/>
</xsl:template>
</xsl:stylesheet>



The preceding XSL stylesheet will return the contents of the /etc/passwd file.

3. Execution of arbitrary Java code:

The XSLT processor has the ability to expose native Java language methods as XSLT functions if they are not disabled.



<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:rt="http://xml.apache.org/xalan/java/java.lang.Runtime" xmlns:ob="http://xml.apache.org/xalan/java/java.lang.Object">
<xsl:template match="/">
<xsl:variable name="rtobject" select="rt:getRuntime()"/>
<xsl:variable name="process" select="rt:exec($rtobject,'ls')"/>
<xsl:variable name="processString" select="ob:toString($process)"/>
<xsl:value-of select="$processString"/>
</xsl:template>
</xsl:stylesheet>



The preceding stylesheet will execute the "ls" command on the server.
References
[1] INJECT-8: Take care interpreting untrusted code Oracle
[2] Standards Mapping - Common Weakness Enumeration CWE ID 494
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[4] Standards Mapping - FIPS200 SI
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[8] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.14.2 Configuration Architectural Requirements (L2 L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.3 File Execution Requirements (L1 L2 L3), 14.2.3 Dependency (L1 L2 L3)
[9] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[10] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[11] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[12] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[14] Standards Mapping - OWASP Top 10 2010 A1 Injection
[15] Standards Mapping - OWASP Top 10 2013 A1 Injection
[16] Standards Mapping - OWASP Top 10 2017 A1 Injection
[17] Standards Mapping - OWASP Top 10 2021 A03 Injection
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.xslt_injection
Abstract
Processing an unvalidated XSL stylesheet can allow an attacker to change the structure and contents of the resultant XML, include arbitrary files from the file system, or execute arbitrary code.
Explanation
XSLT injection occurs when:

1. Data enters a program from an untrusted source.

2. The data is written to an XSL stylesheet.


Applications typically use XSL stylesheet to transform XML documents from one format to another. XSL stylesheets include special functions which enhance the transformation process but introduce additional vulnerabilities if used incorrectly.

The semantics of XSL stylesheets and processing can be altered if an attacker has the ability to write XSL elements in a stylesheet. An attacker could alter the output of a stylesheet such that an XSS (cross-site scripting) attack was enabled, expose the contents of local file system resources, or execute arbitrary code. If the attacker had complete control over the stylesheet submitted to the application, then the attacker could also execute an XXE (XML external entity) injection attack.

Example 1: Here is some code that is vulnerable to XSLT Injection:


...
<?php

$xml = new DOMDocument;
$xml->load('local.xml');

$xsl = new DOMDocument;
$xsl->load($_GET['key']);

$processor = new XSLTProcessor;
$processor->registerPHPFunctions();
$processor->importStyleSheet($xsl);

echo $processor->transformToXML($xml);

?>
...


The code in Example 1 results in three different exploits when the attacker passes the identified XSL to the XSTL processor:

1. XSS:



<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl">
<xsl:template match="/">
<script>alert(123)</script>
</xsl:template>
</xsl:stylesheet>



When the XSL stylesheet is processed, the <script> tag is rendered to the victim's browser allowing a cross-site scripting attack to be performed.

2. Reading of arbitrary files on the server's file system:



<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl">
<xsl:template match="/">
<xsl:copy-of select="document('/etc/passwd')"/>
</xsl:template>
</xsl:stylesheet>



The preceding XSL stylesheet will return the contents of the /etc/passwd file.

3. Execution of arbitrary PHP code:

The XSLT processor has the ability to expose native PHP language methods as XSLT functions by enabling "registerPHPFunctions".



<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl">
<xsl:template match="/">
<xsl:value-of select="php:function('passthru','ls -la')"/>
</xsl:template>
</xsl:stylesheet>



The preceding stylesheet will output the results of the "ls" command on the server.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 494
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.14.2 Configuration Architectural Requirements (L2 L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.3 File Execution Requirements (L1 L2 L3), 14.2.3 Dependency (L1 L2 L3)
[8] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[11] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.php.xslt_injection
Abstract
Processing an unvalidated XSL stylesheet can allow an attacker to change the structure and contents of the resultant XML, include arbitrary files from the file system, or execute arbitrary code.
Explanation
XSLT injection occurs when:

1. Data enters a program from an untrusted source.

2. The data is written to an XSL stylesheet.


Applications typically use XSL stylesheet to transform XML documents from one format to another. XSL stylesheets include special functions which enhance the transformation process but introduce additional vulnerabilities if used incorrectly.

The semantics of XSL stylesheets and processing can be altered if an attacker has the ability to write XSL elements in a stylesheet. An attacker could alter the output of a stylesheet such that an XSS (cross-site scripting) attack was enabled, expose the contents of local file system resources, or execute arbitrary code.

Example 1: Here is some code that is vulnerable to XSLT Injection:


...
xml = StringIO.StringIO(request.POST['xml'])
xslt = StringIO.StringIO(request.POST['xslt'])

xslt_root = etree.XML(xslt)
transform = etree.XSLT(xslt_root)
result_tree = transform(xml)
return render_to_response(template_name, {'result': etree.tostring(result_tree)})
...


The code in Example 1 results in three different exploits when the attacker passes the identified XSL to the XSTL processor:

1. XSS:



<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<script>alert(123)</script>
</xsl:template>
</xsl:stylesheet>



When the XSL stylesheet is processed, the <script> tag is rendered to the victim's browser allowing a cross-site scripting attack to be performed.

2. Reading of arbitrary files on the server's file system:



<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<xsl:copy-of select="document('/etc/passwd')"/>
</xsl:template>
</xsl:stylesheet>



The preceding XSL stylesheet will return the contents of the /etc/passwd file.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 494
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[7] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.14.2 Configuration Architectural Requirements (L2 L3), 10.3.2 Deployed Application Integrity Controls (L1 L2 L3), 12.3.3 File Execution Requirements (L1 L2 L3), 14.2.3 Dependency (L1 L2 L3)
[8] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[9] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[10] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[11] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[12] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[13] Standards Mapping - OWASP Top 10 2010 A1 Injection
[14] Standards Mapping - OWASP Top 10 2013 A1 Injection
[15] Standards Mapping - OWASP Top 10 2017 A1 Injection
[16] Standards Mapping - OWASP Top 10 2021 A03 Injection
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[29] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.python.xslt_injection
Abstract
Writing unvalidated user input to log files can allow an attacker to forge log entries or inject malicious content into the logs.
Explanation
Log forging vulnerabilities occur when:

1. Data enters an application from an untrusted source.

2. The data is written to an application or system log file.

Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.

Interpretation of the log files may be hindered or misdirected if an attacker can supply data to the application that is subsequently logged verbatim. In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. If the log file is processed automatically, the attacker may be able to render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1]. In the worst case, an attacker may inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility [2].

Example 1: The following web application code attempts to read a value from a request object. The value then is logged.


...
DATA log_msg TYPE bal_s_msg.

val = request->get_form_field( 'val' ).

log_msg-msgid = 'XY'.
log_msg-msgty = 'E'.
log_msg-msgno = '123'.
log_msg-msgv1 = 'VAL: '.
log_msg-msgv2 = val.

CALL FUNCTION 'BAL_LOG_MSG_ADD'
EXPORTING
I_S_MSG = log_msg
EXCEPTIONS
LOG_NOT_FOUND = 1
MSG_INCONSISTENT = 2
LOG_IS_FULL = 3
OTHERS = 4.
...


If a user submits the string "FOO" for val, the following entry is logged:


XY E 123 VAL: FOO


However, if an attacker submits the string "FOO XY E 124 VAL: BAR", the following entry is logged:


XY E 123 VAL: FOO XY E 124 VAL: BAR


Clearly, attackers may use this same mechanism to insert arbitrary log entries.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[3] Standards Mapping - Common Weakness Enumeration CWE ID 117
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 AU, SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[18] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 10.3.2
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.abap.log_forging
Abstract
Writing unvalidated user input to log files can allow an attacker to forge log entries or inject malicious content into the logs.
Explanation
Log forging vulnerabilities occur when:

1. Data enters an application from an untrusted source.

2. The data is written to an application or system log file.

Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.

Interpretation of the log files may be hindered or misdirected if an attacker can supply data to the application that is subsequently logged verbatim. In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. If the log file is processed automatically, the attacker may be able to render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1]. In the worst case, an attacker may inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility [2].

Example 1: The following web application code attempts to read an integer value from a request object. If the value fails to parse as an integer, then the input is logged with an error message indicating what happened.


var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var val:String = String(params["username"]);
var value:Number = parseInt(val);
if (value == Number.NaN) {
trace("Failed to parse val = " + val);
}


If a user submits the string "twenty-one" for val, the following entry is logged:


Failed to parse val=twenty-one


However, if an attacker submits the string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", the following entry is logged:


Failed to parse val=twenty-one

User logged out=badguy


Clearly, attackers may use this same mechanism to insert arbitrary log entries.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[3] Standards Mapping - Common Weakness Enumeration CWE ID 117
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 AU, SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[18] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 10.3.2
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.actionscript.log_forging
Abstract
Writing unvalidated user input to log files can allow an attacker to forge log entries or inject malicious content into the logs.
Explanation
Log forging vulnerabilities occur when:

1.Data enters an application from an untrusted source.

2.The data is written to an application or system log file.

Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.

Interpretation of the log files may be hindered or misdirected if an attacker can supply data to the application that is subsequently logged verbatim. In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. If the log file is processed automatically, the attacker may be able to render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1]. In the worst case, an attacker may inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility [2].

Example 1: The following web application code attempts to read an integer value from a request object. If the value fails to parse as an integer, then the input is logged with an error message indicating what happened.


...
string val = (string)Session["val"];
try {
int value = Int32.Parse(val);
}
catch (FormatException fe) {
log.Info("Failed to parse val= " + val);
}
...


If a user submits the string "twenty-one" for val, the following entry is logged:


INFO: Failed to parse val=twenty-one


However, if an attacker submits the string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", the following entry is logged:


INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy


Clearly, attackers may use this same mechanism to insert arbitrary log entries.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[3] Standards Mapping - Common Weakness Enumeration CWE ID 117
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 AU, SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[18] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 10.3.2
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.dotnet.log_forging
Abstract
Writing unvalidated user input to log files could allow an attacker to forge log entries or inject malicious content into the logs.
Explanation
Log forging vulnerabilities occur when:

1. Data enters an application from an untrusted source.

2. The data written to an application or system log file.

Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending upon the nature of the application, log files can be reviewed manually as required, or culled automatically by tools that search the logs for important data points or trends.

Examination of the log files can be hindered or conclusions based on log data can be wrong if an attacker is allowed to supply data to the application that is subsequently logged verbatim. An attacker might insert false entries into the log file by including log entry separator characters in their data. If the log file is processed automatically, the attacker may be able to render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1]. In the worst case, an attacker injects code or other commands into the log file and takes advantage of a vulnerability in the log processing utility [2].

Example 1: The following code from a CGI script accepts a string submitted by the user and attempts to convert it into the long integer value it represents. If the value fails to parse as an integer, then its value is logged with an error message indicating what happened.


long value = strtol(val, &endPtr, 10);
if (*endPtr != '\0')
syslog(LOG_INFO,"Illegal value = %s",val);
...



If a user submits the string "twenty-one" for val, the following entry is logged:


Illegal value=twenty-one


However, if an attacker submits the string "twenty-one\n\nINFO: User logged out=evil", the following entry is logged:


INFO: Illegal value=twenty-one

INFO: User logged out=evil


Clearly, the attacker may use this same mechanism to insert arbitrary log entries. For this type of log forging attack to be effective, an attacker must first identify valid log entry formats, but this can often be accomplished by through system information leaks in the target application.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[3] Standards Mapping - Common Weakness Enumeration CWE ID 117
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 AU, SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[18] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 10.3.2
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.cpp.log_forging
Abstract
Writing unvalidated user input to log files can allow an attacker to forge log entries or inject malicious content into the logs.
Explanation
Log forging vulnerabilities occur when:

1. Data enters an application from an untrusted source.

2. The data is written to an application or system log file.

Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.

Interpretation of the log files may be hindered or misdirected if an attacker can supply data to the application that is subsequently logged verbatim. In the most benign case, an attacker might insert false entries into the log file by providing the application with input that includes appropriate characters. If the log file is processed automatically, the attacker might render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1]. In the worst case, an attacker may inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility [2].

Example 1: The following web application code attempts to read a value from an HTML form. The value then is logged.


...
01 LOGAREA.
05 VALHEADER PIC X(50) VALUE 'VAL: '.
05 VAL PIC X(50).
...

EXEC CICS
WEB READ
FORMFIELD(NAME)
VALUE(VAL)
...
END-EXEC.

EXEC DLI
LOG
FROM(LOGAREA)
LENGTH(50)
END-EXEC.
...


If a user submits the string "FOO" for VAL, the following entry is logged:


VAL: FOO


However, if an attacker submits the string "FOO VAL: BAR", the following entry is logged:


VAL: FOO VAL: BAR


Clearly, attackers may use this same mechanism to insert arbitrary log entries.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[3] Standards Mapping - Common Weakness Enumeration CWE ID 117
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 AU, SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[18] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 10.3.2
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.cobol.log_forging
Abstract
Writing unvalidated user input to log files can allow an attacker to forge log entries or inject malicious content into the logs.
Explanation
Log forging vulnerabilities occur when:

1. Data enters an application from an untrusted source.


2. The data is written to an application or system log file.


Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.

Interpretation of the log files may be hindered or misdirected if an attacker can supply data to the application that is subsequently logged verbatim. In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. If the log file is processed automatically, the attacker may be able to render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1]. In the worst case, an attacker may inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility [2].

Example 1: The following web application code attempts to read an integer value from a web form. If the value fails to parse as an integer, then the input is logged with an error message indicating what happened.


<cflog file="app_log" application="No" Thread="No"
text="Failed to parse val="#Form.val#">


If a user submits the string "twenty-one" for val, the following entry is logged:


"Information",,"02/28/01","14:50:37",,"Failed to parse val=twenty-one"


However, if an attacker submits the string "twenty-one%0a%0a%22Information%22%2C%2C%2202/28/01%22%2C%2214:53:40%22%2C%2C%22User%20logged%20out:%20badguy%22", the following entry is logged:


"Information",,"02/28/01","14:50:37",,"Failed to parse val=twenty-one"

"Information",,"02/28/01","14:53:40",,"User logged out: badguy"


Clearly, attackers may use this same mechanism to insert arbitrary log entries.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[3] Standards Mapping - Common Weakness Enumeration CWE ID 117
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 AU, SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[18] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 10.3.2
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.cfml.log_forging
Abstract
Writing unvalidated user input to log files can allow an attacker to forge log entries or inject malicious content into the logs.
Explanation
Log forging vulnerabilities occur when:

1. Data enters an application from an untrusted source.

2. The data is written to an application or system log file.

Applications typically use log files to store a history of events, view transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.

Interpretation of the log files may be hindered or misdirected if an attacker can supply data to the application that is subsequently logged verbatim. In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. If the log file is processed automatically, the attacker may be able to render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1]. In the worst case, an attacker may inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility [2].

Example 1: The following web application code attempts to read an integer value from a request object. If the value fails to parse as an integer, then the input is logged with an error message indicating what happened.


func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
name := r.FormValue("name")
logout := r.FormValue("logout")
...
if (logout){
...
} else {
log.Printf("Attempt to log out: name: %s logout: %s", name, logout)
}
}


If a user submits the string "twenty-one" for logout and he was able to create a user with name "admin", the following entry is logged:


Attempt to log out: name: admin logout: twenty-one


However, if an attacker is able to create a username "admin+logout:+1+++++++++++++++++++++++", the following entry is logged:


Attempt to log out: name: admin logout: 1 logout: twenty-one
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[3] Standards Mapping - Common Weakness Enumeration CWE ID 117
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 AU, SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[18] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 10.3.2
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.golang.log_forging
Abstract
Writing unvalidated user input to log files can allow an attacker to forge log entries or inject malicious content into the logs.
Explanation
Log forging vulnerabilities occur when:

1. Data enters an application from an untrusted source.

2. The data is written to an application or system log file.

Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.

Interpretation of the log files may be hindered or misdirected if an attacker can supply data to the application that is subsequently logged verbatim. In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. If the log file is processed automatically, the attacker may be able to render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1]. In the worst case, an attacker may inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility [2].

Example 1: The following web application code attempts to read an integer value from a request object. If the value fails to parse as an integer, then the input is logged with an error message indicating what happened.


...
String val = request.getParameter("val");
try {
int value = Integer.parseInt(val);
}
catch (NumberFormatException nfe) {
log.info("Failed to parse val = " + val);
}
...


If a user submits the string "twenty-one" for val, the following entry is logged:


INFO: Failed to parse val=twenty-one


However, if an attacker submits the string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", the following entry is logged:


INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy


Clearly, attackers may use this same mechanism to insert arbitrary log entries.

Some think that in the mobile world, classic web application vulnerabilities, such as log forging, do not make sense -- why would the user attack themself? 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 2: The following code adapts Example 1 to the Android platform.


...
String val = this.getIntent().getExtras().getString("val");
try {
int value = Integer.parseInt();
}
catch (NumberFormatException nfe) {
Log.e(TAG, "Failed to parse val = " + val);
}
...
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[3] IDS03-J. Do not log unsanitized user input CERT
[4] Standards Mapping - Common Weakness Enumeration CWE ID 117
[5] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[7] Standards Mapping - FIPS200 AU, SI
[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[11] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[12] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[17] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[18] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[19] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[20] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[21] Standards Mapping - OWASP Top 10 2010 A1 Injection
[22] Standards Mapping - OWASP Top 10 2013 A1 Injection
[23] Standards Mapping - OWASP Top 10 2017 A1 Injection
[24] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 10.3.2
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[36] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.log_forging
Abstract
Writing unvalidated user input to log files can allow an attacker to forge log entries or inject malicious content into the logs.
Explanation
Log forging vulnerabilities occur when:

1. Data enters an application from an untrusted source.

2. The data is written to an application or system log file.

Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.

Interpretation of the log files may be hindered or misdirected if an attacker can supply data to the application that is subsequently logged verbatim. In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. If the log file is processed automatically, the attacker may be able to render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1]. In the worst case, an attacker may inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility [2].

Example 1: The following web application code attempts to read an integer value from a request object. If the value fails to parse as an integer, then the input is logged with an error message indicating what happened.


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

function listener(request, response){
var val = url.parse(request.url, true)['query']['val'];
if (isNaN(val)){
console.log("INFO: Failed to parse val = " + val);
}
...
}
...
http.createServer(listener).listen(8080);
...


If a user submits the string "twenty-one" for val, the following entry is logged:


INFO: Failed to parse val = twenty-one


However, if an attacker submits the string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", the following entry is logged:


INFO: Failed to parse val=twenty-one

INFO: User logged out=badguy


Clearly, attackers may use this same mechanism to insert arbitrary log entries.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[3] Standards Mapping - Common Weakness Enumeration CWE ID 117
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 AU, SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[18] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 10.3.2
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.javascript.log_forging
Abstract
The identified function writes unvalidated user input to the log. An attacker could take advantage of this behavior to forge log entries or inject malicious content into the log.
Explanation
Log forging vulnerabilities occur when:

1. Data enters an application from an untrusted source.

2. The data is written to an application or system log file.

Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending upon the nature of the application, log files can be reviewed manually as required, or culled automatically by tools that search the logs for important data points or trends.

Examination of the log files can be hindered or conclusions based on log data can be wrong if an attacker is allowed to supply data to the application that is subsequently logged verbatim. An attacker might insert false entries into the log file by including log entry separator characters in their data. If the log file is processed automatically, the attacker may be able to render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1]. In the worst case, an attacker injects code or other commands into the log file and takes advantage of a vulnerability in the log processing utility [2].

Example 1: The following code from a CGI script accepts a string submitted by the user and attempts to convert it into the long integer value it represents. If the value fails to parse as an integer, then its value is logged with an error message indicating what happened.


long value = strtol(val, &endPtr, 10);
if (*endPtr != '\0')
NSLog("Illegal value = %s",val);
...



If a user submits the string "twenty-one" for val, the following entry is logged:


INFO: Illegal value=twenty-one


However, if an attacker submits the string "twenty-one\n\nINFO: User logged out=evil", the following entry is logged:


INFO: Illegal value=twenty-one

INFO: User logged out=evil


Clearly, the attacker may use this same mechanism to insert arbitrary log entries. For this type of log forging attack to be effective, an attacker must first identify valid log entry formats, but this can often be accomplished through system information leaks in the target application.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[3] Standards Mapping - Common Weakness Enumeration CWE ID 117
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 AU, SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[18] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 10.3.2
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.objc.log_forging
Abstract
Writing unvalidated user input to log files can allow an attacker to forge log entries or inject malicious content into the logs.
Explanation
Log forging vulnerabilities occur when:

1. Data enters an application from an untrusted source.

2. The data is written to an application or system log file.

Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.

Interpretation of the log files may be hindered or misdirected if an attacker can supply data to the application that is subsequently logged verbatim. In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. If the log file is processed automatically, the attacker may be able to render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1]. In the worst case, an attacker may inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility [2].

Example 1: The following web application code attempts to read an integer value from a request object. If the value fails to parse as an integer, then the input is logged with an error message indicating what happened.


<?php
$name =$_GET['name'];
...
$logout =$_GET['logout'];

if(is_numeric($logout))
{
...
}
else
{
trigger_error("Attempt to log out: name: $name logout: $val");
}
?>


If a user submits the string "twenty-one" for logout and he was able to create a user with name "admin", the following entry is logged:


PHP Notice: Attempt to log out: name: admin logout: twenty-one


However, if an attacker is able to create a username "admin+logout:+1+++++++++++++++++++++++", the following entry is logged:


PHP Notice: Attempt to log out: name: admin logout: 1 logout: twenty-one
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[3] Standards Mapping - Common Weakness Enumeration CWE ID 117
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 AU, SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[18] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 10.3.2
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.php.log_forging
Abstract
Writing unvalidated user input to log files can allow an attacker to forge log entries or inject malicious content into the logs.
Explanation
Log forging vulnerabilities occur when:

1. Data enters an application from an untrusted source.

2. The data is written to an application or system log file.

Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.

Interpretation of the log files may be hindered or misdirected if an attacker can supply data to the application that is subsequently logged verbatim. In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. If the log file is processed automatically, the attacker may be able to render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1]. In the worst case, an attacker may inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility [2].

Example 1: The following web application code attempts to read an integer value from a request object. If the value fails to parse as an integer, then the input is logged with an error message indicating what happened.


name = req.field('name')
...
logout = req.field('logout')

if (logout):
...
else:
logger.error("Attempt to log out: name: %s logout: %s" % (name,logout))


If a user submits the string "twenty-one" for logout and he was able to create a user with name "admin", the following entry is logged:


Attempt to log out: name: admin logout: twenty-one


However, if an attacker is able to create a username "admin+logout:+1+++++++++++++++++++++++", the following entry is logged:


Attempt to log out: name: admin logout: 1 logout: twenty-one
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[3] Standards Mapping - Common Weakness Enumeration CWE ID 117
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 AU, SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[18] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 10.3.2
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.python.log_forging
Abstract
Writing unvalidated user input to log files can allow an attacker to forge log entries or inject malicious content into the logs.
Explanation
Log forging vulnerabilities occur when:

1. Data enters an application from an untrusted source.

2. The data is written to an application or system log file.

Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.

Interpretation of the log files may be hindered or misdirected if an attacker can supply data to the application that is subsequently logged verbatim. In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. If the log file is processed automatically, the attacker may be able to render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1]. In the worst case, an attacker may inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility [2].

Example 1: The following web application code attempts to read an integer value from a request object. If the value fails to parse as an integer, then the input is logged with an error message indicating what happened.


...
val = req['val']
unless val.respond_to?(:to_int)
logger.info("Failed to parse val")
logger.info(val)
end
...


If a user submits the string "twenty-one" for val, the following entry is logged:


INFO: Failed to parse val
INFO: twenty-one


However, if an attacker submits the string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", the following entry is logged:


INFO: Failed to parse val
INFO: twenty-one

INFO: User logged out=badguy


Clearly, attackers may use this same mechanism to insert arbitrary log entries.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[3] Standards Mapping - Common Weakness Enumeration CWE ID 117
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 AU, SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[18] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 10.3.2
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.ruby.log_forging
Abstract
The identified function writes unvalidated user input to the log. An attacker could take advantage of this behavior to forge log entries or inject malicious content into the log.
Explanation
Log forging vulnerabilities occur when:

1. Data enters an application from an untrusted source.

2. The data is written to an application or system log file.

Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending upon the nature of the application, log files can be reviewed manually as required, or culled automatically by tools that search the logs for important data points or trends.

Examination of the log files can be hindered or conclusions based on log data can be wrong if an attacker is allowed to supply data to the application that is subsequently logged verbatim. An attacker might insert false entries into the log file by including log entry separator characters in their data. If the log file is processed automatically, the attacker may be able to render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1]. In the worst case, an attacker injects code or other commands into the log file and takes advantage of a vulnerability in the log processing utility [2].

Example 1: The following code accepts a string submitted by the user and attempts to convert it into the integer value it represents. If the value fails to parse as an integer, then its value is logged with an error message indicating what happened.


...
let num = Int(param)
if num == nil {
NSLog("Illegal value = %@", param)
}
...


If a user submits the string "twenty-one" for val, the following entry is logged:


INFO: Illegal value = twenty-one


However, if an attacker submits the string "twenty-one\n\nINFO: User logged out=evil", the following entry is logged:


INFO: Illegal value=twenty-one

INFO: User logged out=evil


Clearly, the attacker may use this same mechanism to insert arbitrary log entries. For this type of log forging attack to be effective, an attacker must first identify valid log entry formats, but this can often be accomplished through system information leaks in the target application.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[3] Standards Mapping - Common Weakness Enumeration CWE ID 117
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 AU, SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[18] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 10.3.2
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.swift.log_forging
Abstract
Writing unvalidated user input to log files can allow an attacker to forge log entries or inject malicious content into the logs.
Explanation
Log forging vulnerabilities occur when:

1. Data enters an application from an untrusted source.

2. The data is written to an application or system log file.

Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.

Interpretation of the log files may be hindered or misdirected if an attacker can supply data to the application that is subsequently logged verbatim. In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. If the log file is processed automatically, the attacker may be able to render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1]. In the worst case, an attacker may inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility [2].

Example 1: The following web application code attempts to read an integer value from a request object. If the value fails to parse as an integer, then the input is logged with an error message indicating what happened.


...
Dim Val As Variant
Dim Value As Integer
Set Val = Request.Form("val")
If IsNumeric(Val) Then
Set Value = Val
Else
App.EventLog "Failed to parse val=" & Val, 1
End If
...


If a user submits the string "twenty-one" for val, the following entry is logged:


Failed to parse val=twenty-one


However, if an attacker submits the string "twenty-one%0a%0a+User+logged+out%3dbadguy", the following entry is logged:


Failed to parse val=twenty-one

User logged out=badguy


Clearly, attackers may use this same mechanism to insert arbitrary log entries.
References
[1] A. Muffet The night the log was forged.
[2] G. Hoglund, G. McGraw Exploiting Software Addison-Wesley
[3] Standards Mapping - Common Weakness Enumeration CWE ID 117
[4] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[6] Standards Mapping - FIPS200 AU, SI
[7] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[9] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[11] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), AU-10 Non-Repudiation (P2), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, AU-10 Non-Repudiation, SC-24 Fail in Known State, SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.1 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.1 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 7.3.1 Log Protection Requirements (L2 L3), 7.3.2 Log Protection Requirements (L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[18] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 10.3.2
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-000590 CAT II, APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.vb.log_forging
Abstract
Application is deployed in Development Mode (devMode) allowing arbitrary command execution on the server and leaking detailed information about how the application is coded.
Explanation
Struts 2 has a setting called devMode (development mode). When this setting is enabled, Struts 2 will provide additional logging and debug information, which can significantly speed up development at the cost of a high impact in performance and security. devMode will raise the level of debug or normally ignorable problems to exceptions that would not normally be thrown in normal mode.

devMode also enable some debugging capabilities that allow developers to check variables stored in the Value Stack. These features can be triggered using the debug request parameter:
- debug=console will pop up an OGNL evaluation console allowing developers to evaluate any arbitrary OGNL expression on the server.
- debug=command will allow the developers to submit arbitrary OGNL expressions to be evaluated using the request parameter expression.
- debug=xml will dump the parameters, context, session, and value stack as an XML document.
- debug=browser will dump the parameters, context, session, and value stack in a browseable HTML document.
References
[1] Apache Struts 2 Documentation - devMode
[2] Apache Struts 2 Documentation - Debugging
[3] Meder Kydyraliev Milking a horse or executing remote code in modern Java frameworks
[4] Standards Mapping - Common Weakness Enumeration CWE ID 94, CWE ID 95
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [18] CWE ID 094
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [17] CWE ID 094
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [25] CWE ID 094
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [23] CWE ID 094
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [11] CWE ID 094
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[11] Standards Mapping - FIPS200 SI
[12] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[15] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.2.4 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.5 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.2.8 Sanitization and Sandboxing Requirements (L1 L2 L3), 5.3.6 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[16] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[17] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[18] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[19] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[20] Standards Mapping - OWASP Top 10 2010 A1 Injection
[21] Standards Mapping - OWASP Top 10 2013 A1 Injection
[22] Standards Mapping - OWASP Top 10 2017 A1 Injection
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - SANS Top 25 2009 Risky Resource Management - CWE ID 094
[37] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[60] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.config.java.ognl_expression_injection_struts2_devmode
Abstract
Loading classes from an untrusted source or in an untrusted environment can cause an application to execute malicious commands on behalf of an attacker.
Explanation
Android Class Loading Hijacking vulnerabilities take two forms:

- An attacker can change the name of the directories that the program searches to load classes, thereby pointing the path to one that they have control over: the attacker explicitly controls the paths which should be searched for classes.

- An attacker can change the environment in which the class loads: the attacker implicitly controls what the path name means.

In this case, we are primarily concerned with the first scenario, the possibility that an attacker may be able to control the directories searched for classes to load. Android Class Loading Hijacking 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 library directory to search for classes to load.



3. By executing code from the library path, the application gives the attacker a privilege or capability that the attacker would not otherwise have.

Example 1: The following code uses the user changeable userClassPath to determine the directory in which to search for classes to load.


...
productCategory = this.getIntent().getExtras().getString("userClassPath");
DexClassLoader dexClassLoader = new DexClassLoader(productCategory, optimizedDexOutputPath.getAbsolutePath(), null, getClassLoader());
...


This code allows an attacker to load a library and potentially execute arbitrary code with the elevated privilege of the app by being able to modify the result of userClassPath to point to a different path, which they control. Because the program does not validate the value read from the environment, if an attacker can control the value of userClassPath, then they can fool the application into pointing to a directory that they control and therefore load the classes that they have defined, using the same privileges as the original app.

Example 2: The following code uses the user changeable userOutput to determine the directory the optimized DEX files should be written.


...
productCategory = this.getIntent().getExtras().getString("userOutput");
DexClassLoader dexClassLoader = new DexClassLoader(sanitizedPath, productCategory, null, getClassLoader());
...



This code allows an attacker to specify the output directory for Optimized DEX files (ODEX). This then allows a malicious user to change the value of userOutput to a directory that they control, such as external storage. Once this is achieved, it is simply a matter of replacing the outputted ODEX file with a malicious ODEX file to have this executed with the same privileges as the original application.
References
[1] Android Class Loading Hijacking Symantec
[2] Standards Mapping - Common Weakness Enumeration CWE ID 114
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [3] CWE ID 020
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [3] CWE ID 020
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [4] CWE ID 020
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [4] CWE ID 020
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [6] CWE ID 020
[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [12] CWE ID 020
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[10] Standards Mapping - FIPS200 SI
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.3 Input Validation Requirements (L1 L2 L3), 5.1.4 Input Validation Requirements (L1 L2 L3), 10.2.3 Malicious Code Search (L3)
[15] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[16] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[17] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4
[18] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[19] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[20] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[21] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[22] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[23] Standards Mapping - OWASP Top 10 2021 A03 Injection
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[35] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective 5.4 - Authentication and Access Control, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.2.3 - Web Software Access Controls, Control Objective C.3.2 - Web Software Attack Mitigation
[36] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
desc.dataflow.java.android_class_loading_hijacking
Abstract
The Razor view contains a form but does not include an antiforgery token with that form and therefore may be more susceptible to cross-site request forgery.
Explanation
ASP.NET MVC provides a convenient way to better protect an application against cross-site request forgery by adding an antiforgery token at the HTML form and validating that antiforgery token at the controller. If used, this token is usually included as a hidden form field and validated when the form is submitted, which increases the chances that a request is from your application and not forged.

Generally, a programmer should include this antiforgery token since it increases the cost of malicious scripting against an application.

Example 1:The following Razor code creates a form in the resulting HTML without the built-in defense against cross-site request forgery:


@using (Html.BeginForm(new { ReturnUrl = ViewBag.ReturnUrl })) {
// ... form elements
}
Example 2::The following Razor code creates a form in the resulting HTML without the built-in defense against cross-site request forgery. Note that parameter antiforgery is set to either false or null:


@using (Html.BeginForm("actionName", "controllerName", routeValues, FormMethod.Post, antiforgery: false, htmlAtts)) {
// ... form elements
}
References
[1] HtmlHelper.AntiForgeryToken Method
[2] ValidateAntiForgeryTokenAttribute Class
[3] Standards Mapping - Common Weakness Enumeration CWE ID 352
[4] Standards Mapping - Common Weakness Enumeration Top 25 2019 [9] CWE ID 352
[5] Standards Mapping - Common Weakness Enumeration Top 25 2020 [9] CWE ID 352
[6] Standards Mapping - Common Weakness Enumeration Top 25 2021 [9] CWE ID 352
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [9] CWE ID 352
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [9] CWE ID 352
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [4] CWE ID 352
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-001941, CCI-001942
[11] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-2 Identification and Authentication (Organizational Users) (P1), SC-23 Session Authenticity (P1), SI-10 Information Input Validation (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 IA-2 Identification and Authentication (Organizational Users), SC-23 Session Authenticity, SI-10 Information Input Validation
[14] Standards Mapping - OWASP Application Security Verification Standard 4.0 3.5.3 Token-based Session Management (L2 L3), 4.2.2 Operation Level Access Control (L1 L2 L3), 13.2.3 RESTful Web Service Verification Requirements (L1 L2 L3)
[15] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[16] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization
[17] Standards Mapping - OWASP Top 10 2007 A5 Cross Site Request Forgery (CSRF)
[18] Standards Mapping - OWASP Top 10 2010 A5 Cross-Site Request Forgery (CSRF)
[19] Standards Mapping - OWASP Top 10 2013 A8 Cross-Site Request Forgery (CSRF)
[20] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.5
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.9
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.9
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.9
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.9
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.9
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.3 - Authentication and Access Control
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.3 - Authentication and Access Control
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.3 - Authentication and Access Control, Control Objective C.2.1.2 - Web Software Access Controls
[32] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 352
[33] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 352
[34] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 352
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3585 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3585 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3585 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3585 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3585 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3585 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3585 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II
[57] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-002500 CAT II
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Cross-Site Request Forgery (WASC-09)
[59] Standards Mapping - Web Application Security Consortium 24 + 2 Cross-Site Request Forgery
desc.controlflow.dotnet.aspnet_mvc_bad_practices_form_without_antiforgery_token
Abstract
Deserializing user-controlled objects using BeanUtils may allow attackers to execute arbitrary code on the server, abuse application logic, and/or lead to denial of service.
Explanation
BeanUtils is used to deserialize user-controlled data, in this case a Redis Hash, which contains type discriminators and values to be assigned to the object fields. BeanUtils will reconstruct the object by invoking the setters for these fields, allowing an attacker to pass arbitrary data to an arbitrary class setter. If attackers can specify the classes of the objects to be reconstructed and are able to force the application to run arbitrary setters with user-controlled data, they may be able to execute arbitrary code during the deserialization of the Redis Hash.

Example 1: The following code uses BeanUtilsHashMapper to deserialize Redis Hashes that might enable attacker in control of such Hashes to run arbitrary code.


HashMapper<Person, String, String> hashMapper = new BeanUtilsHashMapper<Person>(Person.class);
Person p = hashMapper.fromHash(untrusted_map);
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 502
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [23] CWE ID 502
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [21] CWE ID 502
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [13] CWE ID 502
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [12] CWE ID 502
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [15] CWE ID 502
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [16] CWE ID 502
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001764, CCI-001774, CCI-002754
[9] Standards Mapping - FIPS200 SI
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 CM-7 Least Functionality (P1), SI-10 Information Input Validation (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 CM-7 Least Functionality, SI-10 Information Input Validation
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.5.2 Input and Output Architectural Requirements (L2 L3), 5.5.1 Deserialization Prevention Requirements (L1 L2 L3), 5.5.3 Deserialization Prevention Requirements (L1 L2 L3)
[14] Standards Mapping - OWASP Mobile 2014 M7 Client Side Injection
[15] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[16] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[18] Standards Mapping - OWASP Top 10 2010 A1 Injection
[19] Standards Mapping - OWASP Top 10 2013 A1 Injection
[20] Standards Mapping - OWASP Top 10 2017 A8 Insecure Deserialization
[21] Standards Mapping - OWASP Top 10 2021 A08 Software and Data Integrity Failures
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 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, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation, Control Objective C.3.5 - Web Software Attack Mitigation
[34] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3570 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3570 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3570 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3570 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3570 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3570 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3570 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 6.2 APSC-DV-001480 CAT II, APSC-DV-001490 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[58] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.dynamic_code_evaluation_unsafe_beanutils_deserialization