A log injection vulnerability arises when the original log entry can be altered to form one or more altogether different entries. Execution of this altered entry may result in log data that is deceptive and fraudulent.
Log injection vulnerabilities may result from including untrusted input in log filesIncluding user input in log files can result in log forging. For example, a user might split a legitimate log entry into two log entries by entering a carriage return and line feed (CRLF) sequence, either of which might be misleading. To prevent such attacks, user input must be sanitized before being used or loggedLog injection attacks can be prevented by sanitizing and validating any untrusted input sent to a log.
Logging unsanitized user input can also result in leaking sensitive data across a trust boundary, or storing sensitive data in a manner that is contrary to local law or regulation. See rule IDS00-J. Sanitize untrusted data passed across a trust boundary for more details on input sanitization.
Log Injection
A log injection vulnerability arises when the original log entry can be altered to form one or more altogether different entries. Execution of this altered entry may result in log data that is deceptive and fraudulent. The primary means of preventing log injection are sanitizing and validating any untrusted input sent to a log.
Noncompliant Code Example
This noncompliant code example logs the user's login name when an invalid request is received. No input sanitization is performed.
Code Block | ||
---|---|---|
| ||
if (loginSuccessful) {
logger.severe("User login succeeded for: " + username);
} else {
logger.severe("User login failed for: " + username);
}
|
Without sanitization, a log injection attack is possible. A standard log message when username
is "david" Consider a system log that records login attempts. A standard log message might look like this:
Code Block |
---|
May 15, 2011 2:19:10 PM java.util.logging.LogManager$RootLogger log SEVERE: User login failed for: david |
If the username user name that is used in a log message was not david
, but rather something like:
...
Code Block |
---|
May 15, 2011 2:19:10 PM java.util.logging.LogManager$RootLogger log
SEVERE: User login failed for: david
May 15, 2011 2:25:52 PM java.util.logging.LogManager log
SEVERE: User login succeeded for: administrator
|
Noncompliant Code Example
This noncompliant code example logs the user's login name when an invalid request is received. No input sanitization is performed.
Code Block | ||
---|---|---|
| ||
if (loginSuccessful) {
logger.severe("User login succeeded for: " + username);
} else {
logger.severe("User login failed for: " + username);
}
|
...
Compliant Solution
This compliant solution sanitizes the user name input before logging it, preventing injection. Refer to rule IDS00-J. Sanitize untrusted data passed across a trust boundary for more details on input sanitization.
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="d18343d2a2727d03-83373585-485a496b-8bfb8758-f853672b86709ef5e27b5ef9"><ac:plain-text-body><![CDATA[ | [ISO/IEC TR 24772:2010 | http://www.aitcnet.org/isai/] | "Injection [RST]" | ]]></ac:plain-text-body></ac:structured-macro> |
CWE ID 144, "Improper Neutralization of Line Delimiters" | ||||
| CWE ID 150, "Improper Neutralization of Escape, Meta, or Control Sequences" |
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="045f506662485878-07024cae-4a0841c2-930aabdf-905a633186160787f7ce63fd"><ac:plain-text-body><![CDATA[ | [[API 2006 | AA. Bibliography#API 06]] | ]]></ac:plain-text-body></ac:structured-macro> |
...