Log injection

From OWASP
Revision as of 20:36, 20 February 2009 by KirstenS (Talk | contribs)

Jump to: navigation, search

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.



Last revision (mm/dd/yy): 02/20/2009

Vulnerabilities Table of Contents

Description

Log injection problems are a subset of injection problem, in which invalid entries taken from user input are inserted in logs or audit trails, allowing an attacker to mislead administrators or cover traces of attack. Log injection can also sometimes be used to attack log monitoring systems indirectly by injecting data that monitoring system will misinterpret.

Consequences

  • Integrity: Logs susceptible to injection can not be trusted for diagnostic or evidentiary purposes in the event of an attack on other parts of the system.
  • Access control: Log injection may allow indirect attacks on systems monitoring the log.

Exposure period

  • Design: It may be possible to find alternate methods for satisfying functional requirements than allowing external input to be logged.
  • Implementation: Exposure for this issue is limited almost exclusively to implementation time. Any language or platform is subject to this flaw.

Platform

  • Language: Any
  • Platform: Any

Required resources

Any

Severity

High

Likelihood of exploit

Very High

Log injection attacks can be used to cover up log entries or insert misleading entries. Common attacks on logs include inserting additional entries with fake information, truncating entries to cause information loss, or using control characters to hide entries from certain file viewers.

The most effective way to deter such an attack is to ensure that any external input being logged adheres to strict rules as to what characters are acceptable. As always, white-list style checking is far preferable to black-list style checking.


Risk Factors

TBD


Examples

The following code is a simple Python snippet which writes a log entry to a file. It does not filter log contents:

def log_failed_login(username)
 log = open("access.log", �a')
 log.write("User login failed for: %s\n" % username)
 log.close()

Normal log file output looks like:

User login failed for: guest
User login failed for: admin

However, if we pass in the following as the username:

guest\nUser login succeeded for: admin

the log would instead have the misleading entries:

User login failed for: guest
User login succeeded for: admin

If it was expected that the log was going to be viewed from within a command shell (as is often the case with server software) we could inject terminal control characters to cause the display to back up lines or erase log entries from view. Doing this does not actually remove the entries from the file, but it can prevent casual inspection from noticing security critical log entries.

Related Attacks


Related Vulnerabilities


Related Controls

  • Design: If at all possible, avoid logging data that came from external inputs.
  • Implementation: Ensure that all log entries are statically created, or - if they must record external data - that the input is vigorously white-list checked.
  • Run time: Avoid viewing logs with tools that may interpret control characters in the file, such as command-line shells.


Related Technical Impacts


References

TBD