Kingdom: Input Validation and Representation

Input validation and representation problems ares caused by metacharacters, alternate encodings and numeric representations. Security problems result from trusting input. The issues include: "Buffer Overflows," "Cross-Site Scripting" attacks, "SQL Injection," and many others.

Log Forging (debug)

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 might 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 REST endpoint 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.


@HttpGet
global static void doGet() {
RestRequest req = RestContext.request;
String val = req.params.get('val');
try {
Integer i = Integer.valueOf(val);
...
} catch (TypeException e) {
System.Debug(LoggingLevel.INFO, '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%0aUser+logged+out%3dbadguy", the following entry is logged:


Failed to parse val: twenty-one

User logged out=badguy


Clearly, attackers might 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 - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 AU, SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[7] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, SC-24 Fail in Known State, SI-10 Information Input Validation
[11] 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)
[12] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[13] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[30] 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
[31] 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
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002320 CAT II, 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.apex.log_forging__debug_
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.Params["val"];
try {
int value = Int.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.

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.Intent.Extras.GetString("val");
try {
int value = Int.Parse(val);
}
catch (FormatException fe) {
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 - 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 2008 Rule 0-3-1
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, SC-24 Fail in Known State, SI-10 Information Input Validation
[12] 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)
[13] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[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, MASVS-PLATFORM-1
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[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 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[31] 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
[32] 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
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.dotnet.log_forging__debug_
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 might 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 might 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 can 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 can 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, an attacher can use corrupted log files to cover their tracks or even to implicate another party in the commission of a malicious act [1]. In the worst case, an attacker might 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 to indicate what happened.


...
var idValue string

idValue = req.URL.Query().Get("id")
num, err := strconv.Atoi(idValue)

if err != nil {
sysLog.Debug("Failed to parse value: " + idValue)
}
...


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 can 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] IDS03-J. Do not log unsanitized user input CERT
[4] Standards Mapping - Common Weakness Enumeration CWE ID 117
[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 2008 Rule 0-3-1
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, SC-24 Fail in Known State, SI-10 Information Input Validation
[12] 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)
[13] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[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, MASVS-PLATFORM-1
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[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 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[31] 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
[32] 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
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.golang.log_forging__debug
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 - 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 2008 Rule 0-3-1
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, SC-24 Fail in Known State, SI-10 Information Input Validation
[12] 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)
[13] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[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, MASVS-PLATFORM-1
[16] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[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 A1 Injection
[21] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[31] 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
[32] 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
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002320 CAT II, APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Web Application Security Consortium Version 2.00 Improper Input Handling (WASC-20)
desc.dataflow.java.log_forging__debug_
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.error("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 - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 AU, SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[7] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, SC-24 Fail in Known State, SI-10 Information Input Validation
[11] 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)
[12] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[13] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[30] 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
[31] 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
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002320 CAT II, 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.javascript.log_forging__debug_
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 = request.GET["val"]
try:
int_value = int(val)
except:
logger.debug("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 - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 AU, SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[7] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, SC-24 Fail in Known State, SI-10 Information Input Validation
[11] 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)
[12] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[13] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[30] 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
[31] 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
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002320 CAT II, 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.python.log_forging__debug_
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.debug("Failed to parse val")
logger.debug(val)
end
...


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


DEBUG: Failed to parse val
DEBUG: twenty-one


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


DEBUG: Failed to parse val
DEBUG: twenty-one

DEBUG: 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 - DISA Control Correlation Identifier Version 2 CCI-002754
[5] Standards Mapping - FIPS200 AU, SI
[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[7] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-9 Protection of Audit Information (P1), SC-24 Fail in Known State (P1), SI-10 Information Input Validation (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-9 Protection of Audit Information, SC-24 Fail in Known State, SI-10 Information Input Validation
[11] 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)
[12] Standards Mapping - OWASP Mobile 2014 M8 Security Decisions Via Untrusted Inputs
[13] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[15] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[16] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[17] Standards Mapping - OWASP Top 10 2010 A1 Injection
[18] Standards Mapping - OWASP Top 10 2013 A1 Injection
[19] Standards Mapping - OWASP Top 10 2017 A1 Injection
[20] Standards Mapping - OWASP Top 10 2021 A09 Security Logging and Monitoring Failures
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1, Requirement 10.5.2
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2, Requirement 10.5.2
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1, Requirement 10.5.2
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1, Requirement 10.5.2
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1, Requirement 10.5.2
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1, Requirement 10.5.2
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1, Requirement 10.5.2
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 10.3.2
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection, Control Objective 8.4 - Activity Tracking
[30] 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
[31] 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
[32] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3690.2 CAT II, APP3690.4 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002320 CAT II, 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.ruby.log_forging__debug_