- Rules
- Risk Assessment Summary
- IDS00-J. Sanitize untrusted data passed across a trust boundary
- IDS01-J. Normalize strings before validating them
- IDS02-J. Canonicalize path names before validating them
- IDS03-J. Do not log unsanitized user input
- IDS04-J. Limit the size of files passed to ZipInputStream
- IDS05-J. Use a subset of ASCII for file and path names
- IDS06-J. Exclude user input from format strings
- IDS07-J. Do not pass untrusted, unsanitized data to the Runtime.exec() method
- IDS08-J. Sanitize untrusted data passed to a regex
- IDS09-J. Do not use locale-dependent methods on locale-dependent data without specifying the appropriate locale
- IDS10-J. Do not split characters between two data structures
- IDS11-J. Eliminate noncharacter code points before validation
- IDS12-J. Perform lossless conversion of String data between differing character encodings
- IDS13-J. Use compatible encodings on both sides of file or network I/O
This chapter is from the book
This chapter is from the book
This chapter is from the book
IDS03-J. Do not log unsanitized user input
A log injection vulnerability arises when a log entry contains unsanitized user input. A malicious user can insert fake log data and consequently deceive system administrators as to the system’s behavior [OWASP 2008]. 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 violates local law or regulation. For example, if a user can inject an unencrypted credit card number into a log file, the system could violate PCI DSS regulations [PCI 2010]. See rule IDS00-J 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$RootLogger log SEVERE: User login succeeded for: administrator
Compliant Solution
This compliant solution sanitizes the username input before logging it, preventing injection attacks. Refer to rule IDS00-J 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 violates a local law or regulation.
|
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
|
IDS03-J |
medium |
probable |
medium |
P8 |
L2 |
Related Guidelines
|
ISO/IEC TR 24772:2010 |
Injection [RST] |
|
MITRE CWE |
CWE-144. Improper neutralization of line delimiters |
|
CWE-150. Improper neutralization of escape, meta, or control sequences |
Bibliography
[API 2006]
[OWASP 2008]
[PCI DSS Standard]