This is about log forging in ASP.NET MVC
Log Forging is Writing unvalidated user input to log files that can allow an attacker to forge log entries or inject malicious content into the logs.
Log forging vulnerabilities occur when:
- Data enters an application from an untrusted source.
- 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
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
Example:
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_v = 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.
How to fix this Issue
Prevent log forging attacks with indirection:
create a set of legitimate log entries that correspond to different events that must be logged and only log entries from this set. To capture dynamic content, such as users logging out of the system, always use server-controlled values rather than user-supplied data. This ensures that the input provided by the user is never used directly in a log entry.
In some situations, this approach is impractical because the set of legitimate resource names is too large or too hard to keep track of. Programmers often resort to blacklisting in these situations. Blacklisting selectively rejects or escapes potentially dangerous characters before using the input. However, any such list of unsafe characters is likely to be incomplete and will almost certainly become out of date.
A better approach is to create a whitelist of characters that are allowed to appear in log entries and accept input composed exclusively of characters in the approved set.
The most critical character in most log forging attacks is the ‘\n’ (newline) character, which should never appear on a log entry whitelist.
