A04:2021 - Insecure design - Information disclosure

November 4, 2024 Celia Catalán

Introduction

The disclosure of information is a security vulnerability, the criticality of which will depend on how sensitive the information obtained is.

It occurs when a web application inadvertently exposes sensitive or confidential data to unauthorized users. This vulnerability can manifest itself in various ways, including the disclosure of technical system details, configuration information, user data, or even source code fragments.

This exposure not only compromises the integrity and confidentiality of the application, but can also provide potential attackers with valuable information to plan and execute more sophisticated attacks against the system.

Impact

The impact of information disclosure on the security of a web application can be significant:

Sensitive data exposure: May reveal sensitive information such as passwords, user data, or infrastructure details.

Facilitating more sophisticated attacks: Attackers can use the information obtained to plan and execute more precise and effective attacks.

Loss of trust: If users discover that the application is vulnerable, it can result in a loss of trust and damage to the organization's reputation.

Regulatory non-compliance: Depending on the nature of the information disclosed, it may lead to violations of privacy and data security regulations.

Compromise of system integrity: The disclosed information may be used to compromise the overall integrity and security of the system.

These impacts underscore the importance of identifying and mitigating information disclosure vulnerabilities in web applications.

Practical Examples

Below are some practical examples of information disclosure vulnerabilities in web applications. These cases illustrate how sensitive information can be inadvertently exposed, providing attackers with valuable data about the infrastructure and internal workings of the application.

Each example includes a description of the scenario, potential impact, and recommended mitigation measures. It is important to understand these cases to improve the security of web applications and protect the organization's sensitive information.

1. Error Messages

This specific case refers to a deliberate technique of causing errors on a web page for a strategic purpose. The main objective of this practice is to induce the system to reveal crucial information about the version of the software being used.

This tactic, while seemingly simple, can provide an attacker with valuable data about the underlying technological infrastructure of the web application. By intentionally forcing these errors, an attacker seeks to exploit system responses to obtain technical details that would normally be hidden.

This information may include not only the exact version of the software, but also other details such as the type of web server, the underlying operating system, or even source code fragments. All of these elements can later be used to plan more sophisticated and targeted attacks.

Summary

An error is deliberately caused in the web application.

The error message generated reveals some information. The information obtained may include software versions, file paths, or server configurations.

Example

There are multiple ways to generate an error on a web page. In this case, we will explain a very common one that occurs when a parameter that is expected to receive a numerical value INTEGER is sent a non-numeric value.

https://<victim_web>/product?productId=2

In this case, the value of the productId parameter will be altered to send a non-numeric value and thus force an error:

https://<victim_web>/product?productId="

In the image, you can see that, in this way, it is possible to force an error and obtain the version of the web server being used.

Mitigation

To prevent this type of vulnerability, it is recommended:

Properly configure error messages so that they do not reveal sensitive information

Implement custom error handling that hides technical details

Keep software and systems updated to reduce known vulnerabilities

Perform regular security tests to identify and fix potential data leaks

2. Default installation files / Debug files

In this scenario, the goal is to identify and locate installation files that have been left in their default configuration. These files can provide valuable and potentially sensitive information about specific versions of software used in the system infrastructure.

The presence of these files can not only reveal crucial technical details, but can also expose known vulnerabilities associated with particular versions of the software, which could be exploited by malicious attackers to compromise system security.

Summary

A recognition phase is executed, where files and directories are searched using files such as sitemap.xml or robots.txt, in addition to crawling tools or directory enumeration.

The debug file or the one generated during installation contains certain sensitive information. Information obtained may include software versions, file paths, server configurations, keys and tokens in clear text

Example

In this case, using the dirsearch directory enumeration tool and SecList's big.txt dictionary, it was possible to enumerate the following file.

dirsearch -u https://victim_web -w ~/Tools/SecLists/Discovery/Web-Content/big.txt

The phpinfo.php file is a diagnostic script commonly used on PHP-enabled web servers. This file, when accessed, displays detailed information about the PHP server configuration, including software versions, enabled extensions, and system variables.

In this case, it can be seen that, among the information contained in this file, there is multiple sensitive information, which can be accessed without prior authentication.

As we can see, leaving this file accessible in a production environment can represent a significant security risk, as it exposes sensitive information that could be exploited by malicious attackers.

Mitigation

To prevent the risks associated with default installation or debugging files it is recommended:

Delete or restrict access to diagnostic files in production environments

Implement robust access controls for sensitive files

Use web application firewalls (WAFs) to block access to potentially dangerous files

Perform regular security audits to identify and remove unnecessary files

Correctly configure file and directory permissions on the web server

Use vulnerability scanning tools to detect exposed files

Implement security policies that prohibit the presence of debugging files in production

Educate developers about the risks of leaving diagnostic files accessible

3. Hidden Files

In this scenario, the goal is to identify and locate hidden files that may contain sensitive or potentially dangerous information for the organization. These files, often inadvertently exposed, can pose a significant risk to enterprise security if discovered and exploited by malicious actors.

Although the directory crawling and enumeration techniques mentioned in previous examples might be applicable, this particular case will focus on alternative, more subtle methods of uncovering these hidden resources. These alternative strategies may include analyzing server responses, inspecting source code, and exploiting common naming patterns, among other more sophisticated and less intrusive approaches.

Summary

A recognition phase is executed, where files and directories are searched using files such as sitemap.xml or robots.txt, in addition to crawling tools or directory enumeration.

The files found through these techniques can range from internal documentation, financial data, user credentials, source code, etc.

Example

For this example, information about the file structure of the web application will be obtained by accessing the robots.txt file.

The robots.txt file is a text file used on websites to tell search engine robots which pages or sections of the site should or should not be crawled and indexed.

https://victim_web/robots.txt

After accessing the /backup directory, you can see in this example that there is a file with the source code of the application.

In this case, it can be seen that the backup file contains source code of the application with sensitive information such as the connection string to a database, where the password is located. In addition to a query to the database where an SQL injection can be sensed.