Difference between revisions of "Information Leakage"

From OWASP
Jump to: navigation, search
Line 2: Line 2:
 
{{Template:Fortify}}
 
{{Template:Fortify}}
  
==Abstract==
+
[[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}}'''
 +
 
 +
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 +
 
 +
[[ASDR Table of Contents]]
 +
__TOC__
  
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
 
  
 
==Description==
 
==Description==
 +
 +
Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.
  
 
An information leak occurs when system data or debugging information leaves the program through an output stream or logging function.
 
An information leak occurs when system data or debugging information leaves the program through an output stream or logging function.
  
==Examples ==
 
  
'''Example 1:'''
+
 
 +
==Risk Factors==
 +
 
 +
TBD
 +
 
 +
 
 +
==Examples==
 +
 
 +
===Example 1===
  
 
The following code prints the path environment variable to the standard error stream:
 
The following code prints the path environment variable to the standard error stream:
Line 22: Line 37:
 
</pre>
 
</pre>
  
'''Example 2:'''
+
===Example 2===
  
 
The following code prints an exception to the standard error stream:
 
The following code prints an exception to the standard error stream:
Line 36: Line 51:
 
Depending upon the system configuration, this information can be dumped to a console, written to a log file, or exposed to a remote user. In some cases the error message tells the attacker precisely what sort of an attack the system will be vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In the example above, the search path could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.
 
Depending upon the system configuration, this information can be dumped to a console, written to a log file, or exposed to a remote user. In some cases the error message tells the attacker precisely what sort of an attack the system will be vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In the example above, the search path could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.
  
==Related Principles==
 
  
[[Use encapsulation]]
+
==Related [[Attacks]]==
 +
 
 +
* [[Attack 1]]
 +
* [[Attack 2]]
 +
 
 +
 
 +
==Related [[Vulnerabilities]]==
 +
 
 +
* [[Vulnerability 1]]
 +
* [[Vulnerabiltiy 2]]
 +
 
 +
==Related [[Controls]]==
 +
 
 +
* [[Control 1]]
 +
* [[Control 2]]
 +
 
 +
 
 +
==Related [[Technical Impacts]]==
 +
 
 +
* [[Technical Impact 1]]
 +
* [[Technical Impact 2]]
 +
 
 +
 
 +
==References==
 +
 
 +
TBD
 +
[[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
  
==Related Threats==
+
Logging and Auditing Vulnerability
  
==Related Attacks==
+
Session Management Vulnerability]]
  
==Related Vulnerabilities==
+
__NOTOC__
  
==Related Countermeasures==
 
  
==Categories==
+
[[Category:OWASP ASDR Project]]
 
[[Category:Error Handling Vulnerability]]
 
[[Category:Error Handling Vulnerability]]
 
[[Category:Logging and Auditing Vulnerability]]
 
[[Category:Logging and Auditing Vulnerability]]

Revision as of 20:01, 30 September 2008

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): 09/30/2008

Vulnerabilities Table of Contents

ASDR Table of Contents

Contents


Description

Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack.

An information leak occurs when system data or debugging information leaves the program through an output stream or logging function.


Risk Factors

TBD


Examples

Example 1

The following code prints the path environment variable to the standard error stream:

	char* path = getenv("PATH");
	... 
	sprintf(stderr, "cannot find exe on path %s\n", path);

Example 2

The following code prints an exception to the standard error stream:

	try {
		...
	} catch (Exception e) {
		e.printStackTrace();
	}

Depending upon the system configuration, this information can be dumped to a console, written to a log file, or exposed to a remote user. In some cases the error message tells the attacker precisely what sort of an attack the system will be vulnerable to. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system. In the example above, the search path could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.


Related Attacks


Related Vulnerabilities

Related Controls


Related Technical Impacts


References

TBD