• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

View
 

Information Leakage (redirected from Information-LeakageCWE-200)

Page history last edited by Robert Auger 11 years, 8 months ago

Project: WASC Threat Classification

Threat Type: Weakness

Reference ID: WASC-13

 

Information Leakage

Information Leakage is an application weakness where an application reveals sensitive data, such as technical details of the web application, environment, or user-specific data. Sensitive data may be used by an attacker to exploit the target web application, its hosting network, or its users. Therefore, leakage of sensitive data should be limited or prevented whenever possible. Information Leakage, in its most common form, is the result of one or more of the following conditions: A failure to scrub out HTML/Script comments containing sensitive information, improper application or server configurations, or differences in page responses for valid versus invalid data.

 

Failure to scrub HTML/Script comments prior to a push to the production environment can result in the leak of sensitive, contextual, information such as server directory structure, SQL query structure, and internal network information. Often a developer will leave comments within the HTML and/or script code to help facilitate the debugging or integration process during the pre-production phase. Although there is no harm in allowing developers to include inline comments within the content they develop, these comments should all be removed prior to the content's public release.

 

Software version numbers and verbose error messages (such as ASP.NET version numbers) are examples of improper server configurations [7]. This information is useful to an attacker by providing detailed insight as to the framework, languages, or pre-built functions being utilized by a web application. Most default server configurations provide software version numbers and verbose error messages for debugging and troubleshooting purposes. Configuration changes can be made to disable these features, preventing the display of this information.

 

Pages that provide different responses based on the validity of the data can also lead to Information Leakage; specifically when data deemed confidential is being revealed as a result of the web application's design. Examples of sensitive data includes (but is not limited to): account numbers, user identifiers (Drivers license number, Passport number, Social Security Numbers, etc.) and user-specific information (passwords, sessions, addresses). Information Leakage in this context deals with exposure of key user data deemed confidential, or secret, that should not be exposed in plain view, even to the user. Credit card numbers and other heavily regulated information are prime examples of user data that needs to be further protected from exposure or leakage even with proper encryption and access controls already in place.

 

Please refer to Insufficient Authentication [8] and Insufficient Authorization [9] for further issues related to protecting and enforcing proper controls over access to data.

 

Example

As mentioned above, there are three general categories of Information Leakage: Insufficient censorship of application content, Improper server configurations, or Dangerous application behavior.

 

Developer comments left in page responses:

        <TABLE border="0" cellPadding="0" cellSpacing="0" height="59" width="591">
        <TBODY>
           <TR>
                <!--If the image files fail to load, check/restart 192.168.0.110 -->
                <TD bgColor="#ffffff" colSpan="5" height="17" width="587"> </TD>
           </TR>
 

Here we see a comment left by the development/QA personnel indicating what one should do if the image files do not show up. The information being disclosed is the internal IP address of the content server that is mentioned explicitly in the code, "192.168.0.110".

 

Improper application or server configurations:

This example of a verbose error message would be the response to an invalid SQL query. SQL Injection attacks do not require any prior knowledge, however the attack process can be greatly expedited by providing the attacker any knowledge related to the structure or format of SQL queries being used by the target application. The information leaked by a verbose error message can provide detailed information on how to construct valid SQL queries for the backend database.

 

The following was returned when placing an apostrophe into the username field of a login page. Improper server configurations:

An Error Has Occurred.
Error Message:
System.Data.OleDb.OleDbException: Syntax error (missing operator) in query expression 'username = ''' and password = 'g''. at
System.Data.OleDb.OleDbCommand.ExecuteCommandTextErrorHandling ( Int32 hr) at
System.Data.OleDb.OleDbCommand.ExecuteCommandTextForSingleResult ( tagDBPARAMS dbParams, Object& executeResult) at

 

In the first error statement, a syntax error is reported. The error message reveals the query parameters that are used in the SQL query: username and password. This leaked information will greatly assist an attacker in beginning to construct SQL Injection attacks against the web application. Please refer to SQL Injection [10] for additional information and solutions.

 

Differences in page response behaviors:

The following is an example of a "forgot password" feature that was included to make an application more "user friendly". However, due to the public access of this feature, an attacker can use this functionality to find valid email addresses or account names.

The password recovery flow performs the following steps:

   1. Ask user for username/email
   -  If username/email is valid continue to steps 2 & 3
   -  If username/email is invalid error with following message: "The username/email you submitted was invalid!"
   2. Message the user that a mail has been sent to their account
   3. Send user a link allowing them to change their password 
 

Information leakage occurs once the entered email address and/or account name is confirmed prior to step-2. The difference in behavior allows an attacker to deduce valid email addresses and/or account names.

 

References

"Best practices with custom error pages in .Net" Microsoft Support

[1] http://support.microsoft.com/default.aspx?scid=kb;en-us;834452

 

"Creating Custom ASP Error Pages" Microsoft Support

[2] http://support.microsoft.com/default.aspx?scid=kb;en-us;224070

 

"Apache Custom Error Pages" Code Style

[3] http://www.codestyle.org/sitemanager/apache/errors-Custom.shtml

 

"Customizing the Look of Error Messages in JSP" DrewFalkman.com

[4] http://www.drewfalkman.com/resources/CustomErrorPages.cfm

 

ColdFusion Custom Error Pages

[5] http://livedocs.macromedia.com/coldfusion/6/Developing_ColdFusion_MX_Applications_with_CFML/Errors6.htm

 

Obfuscators: JAVA

[6] http://www.cs.auckland.ac.nz/~cthombor/Students/hlai/hongying.pdf

 

Server Misconfiguration

[7] http://projects.webappsec.org/Server-Misconfiguration

 

Insufficient Authentication

[8] http://projects.webappsec.org/Insufficient-Authentication

 

Insufficient Authorization

[9] http://projects.webappsec.org/Insufficient-Authorization

 

SQL Injection

[10] http://projects.webappsec.org/SQL-Injection

 

Fingerprinting

[11] http://projects.webappsec.org/Fingerprinting

 

Information Leak (Information Disclosure)

[12]  http://cwe.mitre.org/data/definitions/200.html

 

Comments (0)

You don't have permission to comment on this page.