Difference between revisions of "Information Leakage"

From OWASP
Jump to: navigation, search
(Examples)
(Accidental leaking of sensitive information through error messages)
Line 109: Line 109:
  
 
Another example is passing SQL exceptions to a WebUser without filtering.
 
Another example is passing SQL exceptions to a WebUser without filtering.
 +
 +
 +
===Accidental leaking of sensitive information through sent data===
 +
 +
The accidental leaking of sensitive information through sent data refers to the transmission of data which is either sensitive in and of itself, or useful in the further exploitation of the system through standard data channels.
 +
 +
'''Consequences'''
 +
* Confidentiality: Data leakage results in the compromise of data confidentiality.
 +
 +
'''Exposure period'''
 +
* Requirements specification: Information output may be specified in the requirements documentation.
 +
* Implementation: The final decision as to what data is sent is made at implementation time.
 +
 +
'''Avoidance and mitigation'''
 +
 +
* Requirements specification: Specify data output such that no sensitive data is sent.
 +
* Implementation: Ensure that any possibly sensitive data specified in the requirements is verified with designers to ensure that it is either a calculated risk or mitigated elsewhere.
 +
 +
Accidental data leakage occurs in several places and can essentially be defined as unnecessary data leakage. Any information that is not necessary to the functionality should be removed in order to lower both the overhead and the possibility of security sensitive data being sent.
 +
 +
The following is an actual MySQL error statement:
 +
 +
<pre>
 +
Warning: mysql_pconnect():
 +
Access denied for user: 'root@localhost' (Using password: N1nj4) in /usr/local/www/wi-data/includes/database.inc on line 4
 +
</pre>
  
 
==Related [[Attacks]]==
 
==Related [[Attacks]]==

Revision as of 12:57, 10 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.

Contents


ASDR Table of Contents


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


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.

Accidental leaking of sensitive information through data queries

When trying to keep information confidential, an attacker can often infer some of the information by using statistics.

Consequences

  • Confidentiality: Sensitive information may possibly be disclosed through data queries accidentally.

Exposure period

  • Design: Proper mechanisms for preventing this kind of problem generally need to be identified at the design level.

Avoidance and mitigation

This is a complex topic. See the book Translucent Databases for a good discussion of best practices.

In situations where data should not be tied to individual users, but a large number of users should be able to make queries that "scrub" the identity of users, it may be possible to get information about a user - e.g., by specifying search terms that are known to be unique to that user.

Accidental leaking of sensitive information through error messages

Server messages need to be parsed before being passed on to the user.

Consequences

  • Confidentiality: Often this will either reveal sensitive information which may be used for a later attack or private information stored in the server.

Exposure period

  • Implementation: This flaw is a simple logic issue, introduced entirely at implementation time.
  • Build: It is important to adequately set read privileges and otherwise operationally protect the log.

Platform

  • Languages: Any; it is especially prevalent, however, when dealing with SQL or languages which throw errors.
  • Operating platforms: Any

Avoidance and mitigation

  • Implementation: Any error should be parsed for dangerous revelations.
  • Build: Debugging information should not make its way into a production release.

Discussion

The first thing an attacker may use - once an attack has failed - to stage the next attack is the error information provided by the server.

SQL Injection attacks generally probe the server for information in order to stage a successful attack.

Example: In Java:

try {
  /.../
} catch (Exception e) {
  System.out.println(e);
}

Here you are passing much more data than is needed.

Another example is passing SQL exceptions to a WebUser without filtering.


Accidental leaking of sensitive information through sent data

The accidental leaking of sensitive information through sent data refers to the transmission of data which is either sensitive in and of itself, or useful in the further exploitation of the system through standard data channels.

Consequences

  • Confidentiality: Data leakage results in the compromise of data confidentiality.

Exposure period

  • Requirements specification: Information output may be specified in the requirements documentation.
  • Implementation: The final decision as to what data is sent is made at implementation time.

Avoidance and mitigation

  • Requirements specification: Specify data output such that no sensitive data is sent.
  • Implementation: Ensure that any possibly sensitive data specified in the requirements is verified with designers to ensure that it is either a calculated risk or mitigated elsewhere.

Accidental data leakage occurs in several places and can essentially be defined as unnecessary data leakage. Any information that is not necessary to the functionality should be removed in order to lower both the overhead and the possibility of security sensitive data being sent.

The following is an actual MySQL error statement:

Warning: mysql_pconnect(): 
Access denied for user: 'root@localhost' (Using password: N1nj4) in /usr/local/www/wi-data/includes/database.inc on line 4

Related Attacks


Related Vulnerabilities

Related Controls


Related Technical Impacts


References

TBD