Difference between revisions of "Log Forging"

From OWASP
Jump to: navigation, search
 
(2 intermediate revisions by one user not shown)
Line 1: Line 1:
 
{{Template:Vulnerability}}
 
{{Template:Vulnerability}}
 
{{Template:Fortify}}
 
{{Template:Fortify}}
 
[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
 
  
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
 
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 
[[ASDR Table of Contents]]
 
__TOC__
 
 
  
 
==Description==
 
==Description==
Line 101: Line 95:
 
[[Category:Code Snippet]]
 
[[Category:Code Snippet]]
 
[[Category:Range and Type Error Vulnerability]]
 
[[Category:Range and Type Error Vulnerability]]
 +
[[Category:Vulnerability]]

Latest revision as of 20:35, 20 February 2009

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


This article includes content generously donated to OWASP by Fortify.JPG.

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

Vulnerabilities Table of Contents

Description

Writing unvalidated user input to log files can allow an attacker to forge log entries or inject malicious content into the logs.

Log forging vulnerabilities occur when:

  1. Data enters an application from an untrusted source.
  2. The data is written to an application or system log file.

Applications typically use log files to store a history of events or transactions for later review, statistics gathering, or debugging. Depending on the nature of the application, the task of reviewing log files may be performed manually on an as-needed basis or automated with a tool that automatically culls logs for important events or trending information.

Interpretation of the log files may be hindered or misdirected if an attacker can supply data to the application that is subsequently logged verbatim. In the most benign case, an attacker may be able to insert false entries into the log file by providing the application with input that includes appropriate characters. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. A more subtle attack might involve skewing the log file statistics. Forged or otherwise, corrupted log files can be used to cover an attacker's tracks or even to implicate another party in the commission of a malicious act [1]. In the worst case, an attacker may inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility [2].


Risk Factors

TBD

Examples

The following web application code attempts to read an integer value from a request object. If the value fails to parse as an integer, then the input is logged with an error message indicating what happened.

	...
	String val = request.getParameter("val");
	try {
		int value = Integer.parseInt(val);
	}
	catch (NumberFormatException) {
		log.info("Failed to parse val = " + val);
	}
	...

If a user submits the string "twenty-one" for val, the following entry is logged:

	INFO: Failed to parse val=twenty-one

However, if an attacker submits the string "twenty-one%0a%0aINFO:+User+logged+out%3dbadguy", the following entry is logged:

	INFO: Failed to parse val=twenty-one

	INFO: User logged out=badguy

Clearly, attackers can use this same mechanism to insert arbitrary log entries.


Related Attacks

Related Vulnerabilities


Related Controls


Related Technical Impacts


References