Page History

Including user input in log files can result in log forgingA 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 an attacker 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 loggedto mislead an auditor. 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.

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.

. For example, an attacker might inject a script into a log file such that when the file is viewed using a web browser, the browser could provide the attacker with a copy of the administrator's cookie so that the attacker might gain access as the administrator.

Noncompliant Code Example

This noncompliant code example logs untrusted data from an unauthenticated user without data sanitization.

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 guest Consider a system log that records login attempts. A standard log message might look like this:

May 15, 2011 2:19:10 PM java.util.logging.LogManager$RootLogger log
SEVERE: User login failed for: guest david

If the username that is used in a log message was is not david, guest but rather something a multiline string like this:

guest 
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: guest david
May 15, 2011 2:25:52 PM java.util.logging.LogManager log
SEVERE: User login succeeded for: administrator

Noncompliant Code Example

Compliant Solution (Sanitized User)

This compliant solution sanitizes the username before logging it, preventing injection attacksThis 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: " + sanitizeUser(username));
} else {
  logger.severe("User login failed for: " + sanitizeUser(username));
}

With no sanitization, the log injection described above is possible.

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. The sanitization is done by a dedicated method for sanitizing user names:

if (!public String sanitizeUser(String username) {
  return Pattern.matches("[A-Za-z0-9_]+", username)) {
  // Unsanitized user name
  logger.severe("User login failed for  ? username : "unauthorized user");
}

Compliant Solution (Sanitized Logger)

This compliant solution uses a text logger that automatically sanitizes its input. A sanitized logger saves the developer from having to worry about unsanitized log messages.

Logger sanLogger = new SanitizedTextLogger(logger);

 else if (loginSuccessful) {
  loggersanLogger.severe("User login succeeded for: " + username);
} else {
  loggersanLogger.severe("User login failed for: " + username);
}

The sanitized text logger takes as delegate an actual logger. We assume the logger outputs text log messages to a file, network, or the console, and each log message has no indented lines. The sanitized text logger sanitizes all text to be logged by indenting every line except the first by two spaces. While a malicious user can indent text by more, a malicious user cannot create a fake log entry because all of her output will be indented, except for the real log output.

class SanitizedTextLogger extends Logger {
  Logger delegate;

  public SanitizedTextLogger(Logger delegate) {
    super(delegate.getName(), delegate.getResourceBundleName());
    this.delegate = delegate;
  }

  public String sanitize(String msg) {
    Pattern newline = Pattern.compile("\n");
    Matcher matcher = newline.matcher(msg);
    return matcher.replaceAll("\n  ");
  }

  public void severe(String msg) {
    delegate.severe(sanitize(msg));
  }

  // .. Other Logger methods which must also sanitize their log messages
}

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 violates a local law or regulation.

Automated Detection

Related Guidelines

...

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Bibliography

ISO/IEC TR 24772:2013	Injection [RST]
MITRE CWE	CWE-144, Improper neutralization of line delimiters CWE-150, Improper neutralization of escape, meta, or control sequences CWE-117, Improper Output Neutralization for Logs
MITRE CAPEC	CAPEC-93, Log Injection-Tampering-Forging

Bibliography

[API 2006]	Java Platform, Standard Edition 6 API Specification
[OWASP 2008]
[Seacord 2015]	Image Added IDS03-J. Do not log unsanitized user input LiveLesson

...

Image Added Image Added Image AddedIDS03-J. Validate all data passed in through environment variables and non-default properties      Image Removed      IDS05-J. Limit the size of files passed to ZipInputStream