Information exposure through an error message

Information Exposure Through an Error Message #462

Location in Source Code:-
/com/netflix/zuul/context/RequestContext.java (Line 730)
/com/netflix/zuul/FilterFileManager.java (Line 110)
/com/netflix/zuul/FilterProcessor.java (Line 323, 501, 311, 344, 299, 269, 414, 462)
/com/netflix/zuul/ZuulFilter.java (Line 195, 239)
/com/netflix/zuul/ZuulRunner.java (Line 167)
/com/netflix/zuul/filters/ZuulServletFilter.java (Line 195, 168, 250, 223)
/com/netflix/zuul/http/ZuulServlet.java (Line 196)
/com/netflix/zuul/util/DeepCopy.java (Line 52, 54)

Issue Description and Impact:-

The application generates an error message including raw exceptions, either by not being handled, by explicit returning of the object, or by configuration. Exception details may include sensitive information that could leak out of the exception to the users.
Exposed details about the application’s environment, users, or associated data (for example, stack trace) could enable an attacker to find another flaw and help the attacker to mount an attack.

Recommendation:-

It is recommended that any method that could cause an exception should be wrapped in a try-catch block that: 1. Explicitly handles expected exceptions. 2. Includes a default solution to explicitly handle unexpected exceptions. Further, it is recommended to configure a global handler to prevent unhandled errors from leaving the application.

The text was updated successfully, but these errors were encountered:

Источник

Information Exposure Through Externally-Generated Error Message [CWE-211]

Information Exposure Through Externally-Generated Error Message describes information exposure case where software generates a message with potentially sensitive data and outputs it.

Created: December 10, 2013
Latest Update: December 28, 2020

Table of Content

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

1. Description

This weakness describes information disclosure case where software performs an operation that triggers an error or diagnostic message in an external component. It is a child element of Information Exposure weakness and should be treated as such.

An example of this weakness is an error generated by the programming language interpreter used by software. The provided error message may contain potentially sensitive information and can be used to advance the attack surface.

This weakness can be introduced on design, implementation or operation stages of software development process and is not restricted to certain programming languages; PHP however is the most common and popular example.

The exposed information can be divided into two groups:

1. Exposure of system information
   e.g. file system structure, installation directory, installed software and its versions, etc.
2. Exposure of sensitive data
   e.g. database structure, memory dump, login credentials, etc.

Exposure of error messages is often used to determine vulnerabilities that exist within the application, such as PHP File Inclusion, or SQL injection, and is helpful for performing advanced attacks against the application. Knowledge of web application document root is extremely valuable when exploiting PHP local file inclusions, since it is possible to determine possible log file location to include and execute PHP code stored in webserver log files.

2. Potential impact

An attacker might be able to gain access to restricted information and use it to widen the attack surface. Depending on the disclosed information, it might be possible to escalate privileges within the application or, in rare cases, to gain complete control over the system.

• GDPR & PCI DSS Test
• Website CMS Security Test
• CSP & HTTP Headers Check
• WordPress & Drupal Scanning

Try For Free

3. Exploitation Examples

Let’s have a look at certain common cases of this weakness.

Example 1
The application uses incorrect credentials to connect to database. The error message generated by PHP exposes database user and database host:

Example 2
The application uses the PHP » include() » function to include non-existent file. As a result, PHP generates an error message that includes full path to the application and certain system configuration.

As we can see from examples above, the application outputs data that can be useful for an attacker to e.g. perform a brute-force attack or gain knowledge of file system structure.

4. Severity and CVSS Scoring

Here is a scoring example of installation path disclosure.
3.7 [CVSS:3.0/AV: N /AC: H /PR: N /UI: N /S: U /C: L /I: N /A: N ] — Low severity.

5. Mitigations

The best way to protect your system against this weakness is to disable any output of error messages. Here are basic rules that should be followed when creating and implementing the application. Be sure that the application:

• does not generate errors accessible to others
• does not output debugging information
• handles errors internally and does not display errors that may contain potentially sensitive data
• sanitizes all input and does not send unverified data to external components that might trigger unhandled exceptions (e.g. division by zero, fatal errors).

The environment should be also configured not to output additional information.

Источник

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

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.

• GDPR & PCI DSS Test
• Website CMS Security Test
• CSP & HTTP Headers Check
• WordPress & Drupal Scanning

Try For Free

3. Attack patterns

The following CAPEC vectors are related to information disclosure weakness:

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:

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

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

Источник

try {
    //code
} catch (ParseException e) {
    e.printStackTrace();
} catch (MalformedURLException e) {
    LOG.error("Error in finding Resource Bundle", e);
}

2 ответа