Exploiting information disclosure vulnerabilities

Information disclosure vulnerabilities can arise in various peculiar ways, especially as applications continue to evolve and become more complex over time. Unlike some injection attacks, where several factors determine exploitability. Information disclosures can often lead to direct, standalone attacks while also facilitating future escalations. For instance, what starts as a seemingly non-confidential version disclosure could end up in an attacker enumerating CVEs for that specific software build.

In this article, we explore how to identify and exploit information disclosure vulnerabilities to escalate privileges, read confidential data, and utilize the information for subsequent attacks.

Let's dive in!

What is an information disclosure vulnerability

An information disclosure vulnerability originates when an application unintentionally exposes sensitive data to users who shouldn't have access to it. This data can either lead to a direct attack (e.g., disclosure of PII) or help aid in future attacks (e.g., hard-coded credentials). In both instances, this is due to poor security practices, misconfigurations, or inadequate access controls.

However, it is crucial to note that not all exposed data can necessarily be classified as an information disclosure vulnerability. This is especially true when you're actively participating in bug bounty programs.

Let's examine a few practical examples to help identify information disclosures from non-confidential data references.

Examples of exploitable information disclosure vulnerabilities

As we've previously mentioned, not all data exposures can be considered an information disclosure vulnerability. Some are merely verbose string values that can not lead to a direct or indirect attack and should therefore be disregarded or noted for future reference.

The following examples can be considered information disclosures:

• An exposed configuration of a backup file that contains hard-coded credentials. Think of API keys, authentication credentials, encryption keys, and other types of secrets.

• Accessible API endpoint returning personally identifiable information (PII). Broken access control vulnerabilities can often lead to the disclosure of sensitive information. Think about missing or insufficient Firebase Firestore security rules.

• An error page that returns stack traces and detailed, verbose error messages, including partial or complete server-side code snippets. Think of targets with debugging mode enabled in production environments.

Examples of non-exploitable information disclosure vulnerabilities

As we've noted before, not all verbose data strings can qualify as information disclosures. Let's have a look at a few practical examples of non-sensitive data exposures:

• An error page or server header disclosing server information. Although this can potentially lead to an indirect attack, the attack vector remains highly theoretical and speculative in nature. Technology fingerprinting can actually be useful during reconnaissance, but if it can't lead to a direct vulnerability (such as outdated software), it is often considered a best practice or informative finding.

• Directory listings with no confidential file disclosure. Directory listings originate from a missing index page or a misconfigured web server. However, it is crucial to note that a directory listing by itself cannot be considered a vulnerability unless it provides an attacker with a means to enumerate and access  confidential files (e.g., backups, configuration files, invoices, or receipts containing PII, etc.).

• Comments in HTML source. Stripping HTML comments from production builds is a best practice. However, it is possible that this practice is either ignored or partially applied. HTML comments by themselves cannot be considered a security vulnerability unless they can facilitate direct attacks, such as hard-coded credentials or secrets, references to vulnerable paths, API endpoints, or hosts.

Now that we've acquired a strong foundation of what information disclosure vulnerabilities are, let's explore the various ways you can apply to identify information disclosure vulnerabilities.

Identifying information disclosure vulnerabilities

Information disclosure vulnerabilities can arise from various oversights and other vulnerabilities (think of broken access controls). Therefore, it is crucial to consider all scenarios and test cases when actively testing for information disclosure vulnerabilities.Below is a list of the most commonly occurring ways to discover information disclosures:

Verbose messages and references

Applications can include and return various verbose messages to indicate a successful or failed operation. Developers can also leave (internal) references in the form of comments that are returned to the client in the HTTP response. It is always crucial to carefully inspect any of these messages and look for references that can either lead to direct attacks (such as leaked secrets) or indirect attacks (e.g., references to undocumented API endpoints, in-app features, and hosts).

Broken access controls

Improper validation of access controls to resources and in-app operations frequently results in information disclosures. A few examples include a storage bucket containing PDF invoices and receipts, an API endpoint vulnerable to IDOR that leaks anyone's contact details, and a misconfigured web server that allows access to files located in unprotected web directories (think of the .htaccess file or .git directory).

Injection attacks

Similar to improper access control vulnerabilities, there are plenty of server-side and client-side injection attacks that can result in information disclosure. Think of SQL or NoSQL injections allowing you to retrieve database contents, local file inclusion and disclosure bugs enabling you to view the contents of system-only files, and server-side request forgery (SSRF) vulnerabilities that allow you to reach internal hosts.

Security misconfigurations

A wide range of security misconfigurations can also result in information disclosure vulnerabilities. Examples include the enabling of debug mode in production or public environments, which may expose client PII and system configuration or runtime secrets. CORS misconfigurations also stem from an incorrectly set cross-origin resource sharing policy, often allowing for PII leaks.

Let's now dive deeper into each topic more comprehensively in the next section of this article.

1. Exploiting information disclosure vulnerabilities via verbose messages and references

As we all know, applications return all sorts of data to the client within the HTTP response. In severe cases, this can include hard-coded secrets, as well as subtle references, such as comments referring to undocumented API endpoints or hosts, version disclosures, and internal communications. These references can appear anywhere within the HTTP response.

However, it is also crucial to note that you shouldn't limit yourself to only the target application itself, but also actively search for these online in third-party platforms that your target organization is likely to use (think of GitHub and other developer operations tooling, Atlassian Jira and Freshwork Freshservice, public Trello or Favro boards, public Google Docs and Sheets, etc).

Let's examine a few practical examples.

Information disclosure via HTML comments

Developers sometimes use HTML comments to provide additional context to collaborators or for future reference. These can include documentation, references to other (undocumented) API endpoints or application routes, debugging notes, or even TODO lists that reveal planned features and potential weaknesses to look into.

While it is true that comments are mostly stripped from production code in well-configured build pipelines, they frequently still survive in legacy applications and other application components that receive minimal attention.

Information disclosure via HTML comments

Weaponizing version number disclosures

While version number disclosures do not form a security risk by themselves, they do, however, play a crucial role during reconnaissance. Fingerprinting technologies can often help you enumerate version numbers to look for publicly listed exploits, CVEs, and common misconfigurations.

There are plenty of ways to enumerate version numbers. Some web servers return them in the HTTP response headers, while others return them somewhere in the response body. WordPress targets, for instance, are notoriously known for their outdated and vulnerable plugins. Finding an outdated plugin can sometimes easily result in an XSS, SQLi, or even SSRF vulnerability.

Information disclosure via HTTP response headers

Information disclosure via third-party platforms

Information disclosures don't only occur on the target application itself, sometimes, they spread to third-party platforms. Therefore, it's crucial that you always scour the internet for anything related to your target. This can include searching on Google, through public code commits on GitHub and GitLab, and in third-party platforms that your organization is likely to use.

A quick Google search will reveal that there are thousands of misconfigured third-party platforms, possibly used by your target, that allow for open registration.

Jenkins public signups

2. Exploiting information disclosure vulnerabilities via weak or default credentials

Next to leaked credentials, weak and default credentials are still a common vulnerability in applications. And they can help provide you with unauthorized access to internal portals or elevate your current privileges. Keeping this in mind, it's important to test for weak or default credentials whenever encountering any type of portal behind authentication.

SecLists provides a comprehensive repository with commonly used password credential pairs. There are numerous wordlists online that you can use.

Exploiting information disclosure vulnerabilities via weak or default credentials

3. Exploiting information disclosure vulnerabilities via broken access controls

Improper access controls represent one of the most prevalent sources of information disclosure in modern web applications. In contrast to other weaknesses, such as injection vulnerabilities, broken access controls originate from missing or improper authorization checks. When an application or API fails to properly validate whether a user should access a certain data or component, it can allow attacks to request and view resources that possibly contain sensitive information.

Let's examine a few practical examples.

Directory listings

Web servers sometimes expose directory listings when no index file exists in a directory. Instead of returning a 404 error or a default fallback page, the server lists all files available within the directory instead. Although this isn't necessarily a security weakness, attackers can still use this information to either enumerate new file locations.

If the web server does not incorporate correct access controls, it may allow attackers to directly access any file listed within the disclosed folder.

Information disclosure vulnerability via directory listings

Insecure direct object references (IDORs)

An insecure direct object reference (IDOR) originates from improper access validation, whereby a vulnerable application component takes in a dynamic variable from the client and directly incorporates it in a data-retrieving functionality without validating whether the client is authorized to perform the requested action.

Consider the following API endpoint, which returns invoices based on numeric ID: /api/invoices?invoice_id=1234. Considering you're the attacker, all that holds you back from retrieving other customers' invoices is enumerating other invoice IDs. In this example, changing the invoice_id parameter to something like 1337 would load another customer's invoice with ID 1337. The application authenticated you as a valid user, but never checked whether you have permission to view another customer's invoice. These types of IDOR vulnerabilities can appear anywhere throughout applications and are simple to exploit.

Information disclosure vulnerability via directory listings

Misconfigured cloud storage buckets

Cloud storage buckets, such as Amazon S3, Azure Blob Storage, and Google Cloud Storage, are commonly used to store unstructured data (e.g., images, PDF files, customer exports, etc.). When these buckets are misconfigured, for instance, through a lack of proper access control validation, they may allow anyone with the correct URL to access sensitive files.

Fortunately for us, various open-source tooling can help automate the process of finding and testing buckets for public accessibility. Once discovered, attackers can list contents, download files, and in some cases even upload malicious content if write permissions are also misconfigured.

Information disclosure vulnerability via misconfigured cloud buckets

4. Exploiting information disclosure vulnerabilities via injection attacks

Injection vulnerabilities typically result in some sort of access to the target server, that's why their role in information disclosure is equally significant. Consider a path traversal within the following profile picture retrieving API endpoint: /api/profiles/load-picture?url=https%3A%2F%2Fpublic-assets.example.com%2Fpath%2Fto%2Fprofile-picture.png. In theory, seeing this endpoint would trigger us to test for server-side request forgery vulnerabilities. However, it is essential to note that if our parameter is passed to a similar function, such as PHP's get_file_contents, we'd essentially be allowed to retrieve local files.

Disclosing internal files

Similar to path traversals, injection attacks such as SQLi, XXEs, and SSTIs can also be leveraged to retrieve local files, contents within a database, or reach other data sources, ultimately leading to information disclosure. Open-source, industry-leading tools like SQLMap make retrieving information from a database a breeze.

For instance, classic XXEs target the retrieval of the /etc/passwd file. However, with a local file disclosure, we can also target the files that contain the application's source code, ultimately, allowing us to expose the application logic without any restrictions. This information can also be used to identify more vulnerabilities.

Exploiting a simple XML external entity (XXE) injection vulnerability

Reaching internal services

In addition to retrieving and reading local files, we can also weaponize some injection attacks, such as SSRFs and XXEs, to reach internal-only services. Some internal resources (think cloud metadata endpoints) are vital to support an organization's workflows, and these often hold or process sensitive data. SSRF attacks can help us access these internal resources, ultimately allowing us to read confidential data.

Example of a leaked AWS Metadata Endpoint

Disclosing client-side data with XSS

Similar to server-side injection attacks, some client-side injection can also lead to information disclosures. Cross-site scripting vulnerabilities are a perfect example of this. While most researchers cease any escalation after triggering the pop-up window, the impact of XSS can far exceed a simple alert function call.

For instance, XSS vulnerabilities can be used to fetch sensitive non-HTTPOnly cookies, any data stored within the client's browser storage, and also reach authenticated endpoints on behalf of the victim. In most real-world attacks, this information is subsequently sent to the attacker's end.

Weaponizing blind XSS for information disclosure

The disclosure impact increases significantly with blind XSS, where payloads execute in contexts the attacker cannot directly access or observe. Unlike reflected, DOM-based, or stored XSS, where attackers see immediate results in their own browser session, blind XSS triggers when someone else views the compromised content, often administrators, support staff, or internal employees reviewing user data.

When an attacker injects a payload into a support ticket, feedback form, or application log, it remains untriggered until a privileged user opens it in their authenticated session. At that moment, the JavaScript executes with all the permissions and access rights of that privileged user, allowing it to reach internal admin panels, access sensitive dashboards, and interact with functionality completely unavailable to regular users, such as your account.

After payload execution, the attacker receives a callback containing the collected data (such as session tokens, page contents, and internal URLs, as well as other data they could never access directly), effectively weaponizing the victim's elevated privileges to leak confidential data.

5. Exploiting information disclosure vulnerabilities via security misconfigurations

Security misconfigurations occur when best practices are partially followed or entirely ignored. Unlike vulnerabilities in code logic or missing input validation, misconfigurations are failures in deployment, setup, and operational practices. We can easily spot these as long as we're equipped with enough knowledge about the underlying technology. Let's have a look at a few practical examples.

Debug mode enabled

Almost any major framework and platform includes debug features that dramatically increase visibility into application internals. These features are typically introduced to help developers troubleshoot problems during development by exposing detailed error information, variable states, and execution traces. The issue lies in when these debugging features are publicly accessible to attackers, as they can disclose a significant amount of confidential data. Think of error pages returning partial or entire code snippets or API endpoints returning live server statistics, including client data (such as IP addresses, full request paths, and HTTP bodies, etc.) or even plain text runtime secrets.

Information disclosure vulnerability via debug mode

Misconfigurations in cloud buckets

As we've seen earlier, cloud buckets can expose sensitive data if they're left misconfigured. These typical misconfigurations involve setting bucket permissions to "public-read" during development or testing and forgetting to restrict access before moving to production. Sometimes, this is indeed intentional when developers need to serve images or static assets that should be publicly accessible. The issue arises when this same permissive policy is applied to buckets containing sensitive data.

In our Cloudflare R2 security research article, we've identified that some targets have left the R2.dev feature enabled, a functionality that would have temporarily left your bucket exposed to unauthenticated visitors. This can be useful for testing purposes, however, this can also be weaponized by attackers who are on the lookout for sensitive information.

Enumerating CF R2 cloud buckets

Cross-Origin Resource Sharing (CORS) misconfigurations

Web servers can also be left misconfigured, for instance, by  not employing any browser security measures or by setting incorrect security headers. A clear example is CORS misconfigurations. CORS policies control which external domains can access resources through cross-origin requests from web browsers. Proper CORS configuration protects sensitive data from being accessed by malicious origin sites, while misconfigurations can expose internal APIs, user data, and authenticated operations to unauthorized origins.

Conclusion

Information disclosure vulnerabilities can originate from a vast number of vulnerability classes, and this should be taken into account. In this article, we've explored the importance of testing for information disclosures, where they appear, how to test for them, and, most importantly, filtering out the false positives.

So, you've just learned something new about exploiting information disclosures... Right now, it's time to put your skills to the test! You can start by practicing on vulnerable labs and CTFs or... browse through our 70+ public bug bounty programs on Intigriti, and who knows, maybe earn a bounty on your next submission!