Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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 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 misleadingto 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 violates local law or regulation. For example, if a user can inject an unencrypted credit card number an attacker might inject a script into a log file such that when the file is viewed using a web browser, the system could violate PCI DSS regulations [PCI 2010]. See rule IDS00-J. Sanitize untrusted data passed across a trust boundary for more details on input sanitizationbrowser 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 the user's login name when an invalid request is received. No input sanitization is performed untrusted data from an unauthenticated user without data sanitization.

Code Block
bgColor#FFCCCC

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 guest might look like this:

Code Block

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

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

Code Block
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:

Code Block

May 15, 2011 2:19:10 PM java.util.logging.LogManager$RootLogger log
SEVERE: User login failed for: davidguest 
May 15, 2011 2:25:52 PM java.util.logging.LogManager log
SEVERE: User login succeeded for: administrator

Compliant Solution (Sanitized User)

This compliant solution just validates sanitizes the username input before  before logging it, preventing injection attacks. Refer to rule IDS00-J. Sanitize untrusted data passed across a trust boundary for more details on input sanitization..

Code Block
bgColor#ccccff
if (loginSuccessful) {
  logger.severe("User login succeeded for: " + sanitizeUser(username));
} else {
  logger.severe("User login failed for: " + sanitizeUser(username));
}

The sanitization is done by a dedicated method for sanitizing user names:

Code Block
bgColor#ccccff

if (!public String sanitizeUser(String username) {
  return Pattern.matches("[A-Za-z0-9_]+", username)) {
  // Unsanitized username
  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.


Code Block
bgColor#ccccff
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.

Code Block
bgColor#ccccff
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 violates a local law or regulation.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

IDS03-J

medium

Medium

probable

Probable

medium

Medium

P8

L2

Automated Detection

ToolVersionCheckerDescription
The Checker Framework

Include Page
The Checker Framework_V
The Checker Framework_V

Tainting CheckerTrust and security errors (see Chapter 8)
CodeSonar
Include Page
CodeSonar_V
CodeSonar_V

JAVA.IO.TAINT.LOG

Tainted Log (Java)

Fortify
Log_ForgingImplemented
Klocwork

Include Page
Klocwork_V
Klocwork_V

Related Guidelines

SVLOG_FORGINGImplemented
Parasoft Jtest
Include Page
Parasoft_V
Parasoft_V
CERT.IDS03.TDLOGProtect against log forging

Related Guidelines

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="16109623-e334-4ce3-84a1-b9220e0adc43"><ac:plain-text-body><![CDATA[

[

http://www.aitcnet.org/isai/]

ISO/IEC TR 24772:

2010

2013

Injection [RST]

]]></ac:plain-text-body></ac:structured-macro>

MITRE CWE

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="a13ed98a-e400-4c98-aa01-451e0b7b5bcf"><ac:plain-text-body><![CDATA[

[[API 2006

AA. References#API 06]]

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="42907fe9-dc5b-4c9a-bca7-d87fe6fd3144"><ac:plain-text-body><![CDATA[

[[OWASP 2008

AA. References#OWASP 08]]

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="b9af77df-e526-4331-bef3-80ba489127d1"><ac:plain-text-body><![CDATA[

[[PCI DSS Standard

https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml]]

]]></ac:plain-text-body></ac:structured-macro>

CWE-117, Improper Output Neutralization for Logs 

MITRE CAPEC

CAPEC-93, Log Injection-Tampering-Forging

Bibliography


...

Image Added Image Added Image Removed      Image Removed