Information Exposure [CWE-200]

Information disclosure weakness describes intentional or unintentional disclosure of information that is considered sensitive.

Created: September 11, 2012
Latest Update: December 28, 2020

Table of Content

1. Description
2. Potential impact
3. Attack patterns
4. Affected software
5. Exploitation Examples
6. Severity and CVSS Scoring
7. Mitigations
8. References
9. Latest Related Security Advisories

Want to have an in-depth understanding of all modern aspects of
Information Exposure [CWE-200]? Read carefully this article and bookmark it to get back later, we regularly update this page.

1. Description

This weakness could be result of numerous types of problems that involve exposure of sensitive information. The information is considered sensitive when:

• It is sensitive within the product functionality (e.g. information with restricted access, private messages, etc.)
• It contains data about the product itself, its environment or the related system that is not intended be disclosed by the application.

CWE-200 is a parent for the following weaknesses:

• CWE-201: Information Exposure Through Sent Data
• CWE-202: Exposure of Sensitive Data Through Data Queries
• CWE-203: Information Exposure Through Discrepancy
• CWE-209: Information Exposure Through an Error Message
• CWE-211: Information Exposure Through Externally-Generated Error Message
• CWE-212: Improper Cross-boundary Removal of Sensitive Data
• CWE-213: Intentional Information Exposure
• CWE-214: Information Exposure Through Process Environment
• CWE-215: Information Exposure Through Debug Information
• CWE-226: Sensitive Information Uncleared Before Release
• CWE-497: Exposure of System Data to an Unauthorized Control Sphere
• CWE-524: Information Exposure Through Caching
• CWE-526: Information Exposure Through Environmental Variables
• CWE-538: File and Directory Information Exposure
• CWE-598: Information Exposure Through Query Strings in GET Request
• CWE-612: Information Exposure Through Indexing of Private Data

2. Potential impact

Potential impact can vary depending on application, environment and other circumstances. There are many different problems that involve information leaks and their severity can be widely ranged based on information that is disclosed.

3. Attack patterns

The following CAPEC vectors are related to information disclosure weakness:

• CAPEC-13: Subverting Environment Variable Values
• CAPEC-22: Exploiting Trust in Client (aka Make the Client Invisible)
• CAPEC-59: Session Credential Falsification through Prediction
• CAPEC-60: Reusing Session IDs (aka Session Replay)
• CAPEC-79: Using Slashes in Alternate Encoding
• CAPEC-169: Footprinting
• CAPEC-281: Analytic Attacks
• CAPEC-472: Browser Fingerprinting

In WASC Threat Classification this weakness is described as an attack and weakness under WASC-45 (Fingerprinting) and WASC-13 (Information Leakage) respectively.

4. Affected software

Basically all types of software can be vulnerable to this issue.

5. Exploitation Examples

Let's have a look at the HTB23123 security advisory (CVE-2012-5696). The vulnerability allows a malicious user to access configuration file via HTTP request by accessing the file directly. We will use the following URL to access the configuration file:
http://[host]/frameworkgui/config

The output is shown on the image below:

As we can see, it is possible to view contents of the file that contains credentials for accessing the database along with other configuration options.

6. Severity and CVSS Scoring

When scoring information disclosure weaknesses security specialists must consider the maximum possible impact. If an attacker can gain access to certain parts of information or he does not have control over what is obtained the weakness should be scored as C:P. If an attacker is able to read all system data (e.g. files, memory) it should be scored as C:C. Usually, when information exposure is the only weakness presented in application it is scored as C:P.

For a web application disclosure of files should be scored as:
7.5 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N] – High severity.

7. Mitigations

For CWE-211 [Information Exposure Through Externally-Generated Error Message] mitigation techniques please refer to this article.

The main approach in defending sensitive data is to use safe mechanisms to store and access information. But first, information assets should be identified in order to determine what exactly should be protected and how. There are certain certifications, standards and compliance requirements when dealing with classified information, which are far beyond the scope of this article. Here, however, we will try to provide basic understanding of information types and give general advices to developers. We suggest dividing information into two categories:

System information

It should be obvious from the category name that here we are talking about system related data, such as file system structure, system users, installed software, system log files, etc. This is basically any information that reveals environment of the application or asset. To prevent system information exposure follow these recommendations:

1. General recommendations
   
   • Never run applications in debug mode on production servers,
   • Use least privilege approach and proper file system permissions,
   • Run remotely accessible applications in chroot/sandbox environments,
   • Never store log files with world-readable permissions;
   
   
2. Web site environment
   
   • Disable directory listing to prevent exposure of web site structure and potentially sensitive files,
   • Use custom error pages that prevent from displaying excessive system information,
   • Disable error reporting output into the client's browser,
   • Use IP-based approach to access sensitive directories or restrict access to directories otherwise.

You can use the following Cheat Sheet when configuring your webserver:

Action needed	Examples
Disable debugging output PHP	Change the value for "display_errors" to "off" in PHP configuration file php.ini: display_errors=0
Disable debugging output IIS	Edit the Web.config file file and set "debug" attribute to "false": <compilation   debug="false" />
Disable debugging output ColdFusion	Use the cfsetting tag showDebugOutput attribute to turn off debugging output for a specific page: <cfsetting showDebugOutput="No">
Disable debugging output NodeJS	Set the NODE_ENV to production to disable stack traces being returned upon error conditions: set NODE_ENV=production
Custom error pages IIS	To add custom error pages follow instructions below: To add a custom error, use the following syntax: appcmd set config /section:httpErrors /+"[statusCode=' int ',subStatusCode=' int ', prefixLanguageFilePath=' string ',path=' string ', responseMode = 'File|ExecuteURL|Redirect']" For more information on custom error pages refer to TechNet web site: http://technet.microsoft.com/en-us/library/cc753103(v=ws.10).aspx
Custom error pages in Apache	To change the default error pages use the "ErrorDocument" directive in your webserver configuration. These pages can be changed globally for every web site hosted by Apache HTTP server using httpd.conf file or for each site via .htaccess files. For example: ErrorDocument 500 "Sorry, our script crashed. Oh dear" For more information on custom error pages refer to official documentation: http://httpd.apache.org/docs/current/custom-error.html
Custom error pages Nginx	Use the following configuration to change the default error page: error_page {ErrNo} / {ErrNo}.html; location /{ErrNo}.html {   internal; } where ErrNo is number of HTTP Error. For example: error_page 403 /403.html;   location = /403.html {     root html;     allow all;   } For more information refer to official documentation: http://nginx.org/en/docs/http/ngx_http_core_module.html#error_page
Custom error pages NodeJS	You can create custom classes in NodeJS that handle error conditions, by extending the Error class: class CustomError extends Error {
Restrict access Nginx	You can restrict access to sensitive script "/admin.php" using the following configuration: location = /admin.php {   deny all; }
Restrict access IIS	You can restrict access to sensitive script "admin.aspx" using the following configuration: <location path="admin.aspx">   <system.webServer>     <security>       <authorization>         <remove users="*" roles="" verbs="" />         <add accessType="Allow" roles="Administrators" />       </authorization>     </security>   </system.webServer> </location>
Restrict access Apache	You can restrict access to sensitive script "admin.php" using the following configuration: <Files "admin.php">   Order allow,deny   Deny from all </Files>

Sensitive information

This category contains the actual information we want to protect, such as passwords, valuable data etc. Developers should always pay attention to privileges within the application and information that can be accessed by application itself. All sensitive data should be encrypted and stored in safe places. This particularly applies to:

• Passwords,
• Backup copies,
• Any other information that might have a value for potential intruder (e.g. sensitive documents, sensitive configuration data, etc.).

When deploying the application, pay attention to files that may contain sensitive data as well as access control lists applied to these files. When dealing with web applications, place all sensitive content outside the webroot directory or make sure that access to these files is restricted to application itself (e.g. the file cannot be directly accessed using a web browser). Never output debug information to user's browser, use log files outside the webroot directory instead.

8. References

1. CWE-200: Information Exposure [cwe.mitre.org]
2. Information Leakage [projects.webappsec.org]

9. Information Exposure Vulnerabilities, Exploits and Examples

• HTB23123: Multiple Vulnerabilities in Smartphone Pentest Framework (SPF)
• HTB22906: Multiple Vulnerabilities in Collabtive
• HTB23060: Multiple vulnerabilities in OBM
• HTB23055: Multiple Vulnerabilities in webERP

Copyright Disclaimer: Any above-mentioned content can be copied and used for non-commercial purposes only if proper credit to ImmuniWeb is given.

↑ Back to Top