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 files. 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. Log 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.
Noncompliant Code Example
This noncompliant code example logs the user's login name when an invalid request is received. No input sanitization is performed.
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" might look like this:
May 15, 2011 2:19:10 PM java.util.logging.LogManager$RootLogger log SEVERE: User login failed for: david
If the username
that is used in a log message was not david
, but rather a multiline string like this:
david May 15, 2011 2:25:52 PM java.util.logging.LogManager$RootLogger log SEVERE: User login succeeded for: administrator
the log would contain the following misleading data:
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
Compliant Solution
This compliant solution sanitizes the username
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.
if (!Pattern.matches("[A-Za-z0-9_]+", username)) { // Unsanitized username logger.severe("User login failed for unauthorized user"); } else if (loginSuccessful) { logger.severe("User login succeeded for: " + username); } else { logger.severe("User login failed for: " + username); }
Risk Assessment
Allowing unvalidated user input to be logged can result in forging of log entries, leaking secure information, or storing sensitive data in a manner that is contrary to local law.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
IDS03-J |
medium |
probable |
medium |
P8 |
L2 |
Related Guidelines
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="ad981db0-75cb-4fdb-b002-9247cebb39ed"><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-144, "Improper Neutralization of Line Delimiters" |
||||
|
CWE-150, "Improper Neutralization of Escape, Meta, or Control Sequences" |
Bibliography
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="9438e6f7-84c2-4532-aa28-97ce9e58e928"><ac:plain-text-body><![CDATA[ |
[[API 2006 |
AA. Bibliography#API 06]] |
]]></ac:plain-text-body></ac:structured-macro> |
IDS03-J. Validate all data passed in through environment variables and non-default properties IDS04-J. Limit the size of files passed to ZipInputStream