Information Leakage

From OWASP
Revision as of 12:54, 10 February 2009 by KirstenS (Talk | contribs)

Jump to: navigation, search

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.

Related Attacks


Related Vulnerabilities

Related Controls


Related Technical Impacts


References

TBD