The software does not properly sanitize or incorrectly
sanitizes output that is written to logs.
Extended Description
This can allow an attacker to forge log entries or inject malicious
content into logs.
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.
Time of Introduction
Implementation
Applicable Platforms
Languages
All
Common Consequences
Scope
Effect
Integrity
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. Forged or otherwise corrupted log
files can be used to cover an attacker's tracks, possibly by skewing
statistics, or even to implicate another party in the commission of a
malicious act. 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. An attacker may inject code or other
commands into the log file and take advantage of a vulnerability in the
log processing utility.
Likelihood of Exploit
Medium
Demonstrative Examples
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.
(Bad Code)
Java
String val = request.getParameter("val");
try {
int value = Integer.parseInt(val);
}
catch (NumberFormatException) {
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 can use this same mechanism to
insert arbitrary log entries.
Chain: inject fake log entries with fake
timestamps using CRLF injection
Potential Mitigations
Phase
Description
Architecture and Design
Assume all input is malicious. Use a standard input validation
mechanism to validate all input for length, type, syntax, and business
rules before accepting the data to be displayed or stored. Use an
"accept known good" validation strategy.
Use and specify a strong output encoding (such as ISO 8859-1 or UTF
8).
Do not rely exclusively on blacklist validation to detect malicious
input or to encode output. There are too many variants to encode a
character; you're likely to miss some variants.
Inputs should be decoded and canonicalized to the application's
current internal representation before being validated. Make sure that
your application does not decode the same input twice. Such errors could
be used to bypass whitelist schemes by introducing dangerous inputs
after they have been checked.
Background Details
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.
Weakness Ordinalities
Ordinality
Description
Primary
(where the
weakness exists independent of other weaknesses)
Description
