Accepting user input in log files can result in log forging. For example, a user could be able to break a legitimate log entry into two log entries by entering carriage return and line feed (CRLF) sequence. The second entry could be intentionally misleading; for example, it may warn the administrator that a reboot is required to install critical security updates. Consequently, user input must be sanitized before being used or logged.
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 IDS01-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 user name when an invalid request is received. No input sanitization is performed.
logger.severe("Invalid username:" + getUserName());
Compliant Solution
This compliant solution sanitizes the user name input before logging it. Refer to rule IDS01-J. Sanitize untrusted data passed across a trust boundary for more details on input sanitization.
String username = getUserName();
sanitize(username);
logger.severe("Invalid username:" + 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 |
|---|---|---|---|---|---|
IDS05-J |
medium |
probable |
medium |
P8 |
L2 |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Bibliography
[[API 2006]]
[[MITRE 2009]] CWE ID 144
"Improper Neutralization of Line Delimiters" and CWE ID 150 "Improper Neutralization of Escape, Meta, or Control Sequences"
IDS03-J. Sanitize non-character code points before performing other sanitization IDS06-J. Do not pass untrusted, unsanitized data to the Runtime.exec() method