Difference between revisions of "Log injection"

From OWASP
Jump to: navigation, search
Line 2: Line 2:
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
  
[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
+
__TOC__
 +
 
 +
[[ASDR Table of Contents]]
  
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
+
[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
 
+
[[ASDR Table of Contents]]
+
__TOC__
+
  
  
Line 111: Line 110:
  
 
==References==
 
==References==
Note: A reference to related [http://cwe.mitre.org/ CWE] or [http://capec.mitre.org/ CAPEC] article should be added when exists. Eg:
+
TBD
 
+
* [http://cwe.mitre.org/data/definitions/79.html CWE 79].
+
* http://www.link1.com
+
* [http://www.link2.com Title for the link2]
+
 
+
[[Category:FIXME|add links
+
 
+
In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>
+
 
+
Availability Vulnerability
+
 
+
Authorization Vulnerability
+
 
+
Authentication Vulnerability
+
 
+
Concurrency Vulnerability
+
 
+
Configuration Vulnerability
+
 
+
Cryptographic Vulnerability
+
 
+
Encoding Vulnerability
+
 
+
Error Handling Vulnerability
+
 
+
Input Validation Vulnerability
+
 
+
Logging and Auditing Vulnerability
+
  
Session Management Vulnerability]]
 
  
 
__NOTOC__
 
__NOTOC__

Revision as of 16:04, 2 November 2008

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



Contents


ASDR Table of Contents

Last revision (mm/dd/yy): 11/2/2008


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