Information Disclosure Vulnerability

5 min readFeb 14, 2022

Hello guys👋👋 ,Prajit here from the BUG XS Team and Cyber Sapiens United LLP Cybersecurity and Red Team Intern, in this I am regularly given some interesting tasks, In my thirteenth task I was given to research about Information Disclosure Vulnerability.

What is Information Disclosure Vulnerability?

Information disclosure, also known as information leakage, is when a website unintentionally reveals sensitive information to its users.

Depending on the context, websites may leak all kinds of information to a potential attacker, including:

● private, personal information, such as personal messages, financial data, health records, geographic location, or contact details

● system status and environment, such as the operating system and installed packages

● business secrets and intellectual property

● network status and configuration

● the product’s own code or internal state

● metadata, e.g. logging of connections or message headers

● indirect information, such as a discrepancy between two internal operations that can be observed by an outsider

Information might be sensitive to different parties, each of which may have their own expectations for whether the information should be protected. These parties include:

● the product’s own users

● people or organizations whose information is created or used by the product, even if they are not direct product users

● the product’s administrators, including the admins of the system(s) and/or networks on which the product operates

● the developer

Methods to Find Information Disclosure Vulnerability:

Fuzzing the URL Domains:

In this method you enumerate the subdomains, and you use a proper wordlist to fuzz the endpoint. You can use dirsearch and ffuf to carry out this job.

Use of proper wordlist is also important to make this effective. You can use Assetnote Wordlists or six2dez/OneListForAll: Rockyou for web fuzzing (github.com) for fuzzing.

With this method you can not only find sensitive information disclosure but also get more attack vectors to hunt for different vulnerabilities, for e.g. hidden pages and parameters.

2. Viewing Page Source of a Page:

In this method you have to look for sensitive information like API Keys , tokens, creds, etc in the page source of a certain web page.

Just visit a web page do right click > View page source

Now use the search functionality to search for api keys and other private information being disclosed there.

This is one of the scenarios which is missed by many people and even developers, so you can find sensitive information here.

3. Recon on JS Files:

JS Files are said to be gold mine of information, there is a high chances that there will be a sensitive information like tokens , api keys, etc

There are many tools to get JS Files from a website but the most simple way is via Burp Suite.

In Target Tab of Burpsuite, Right click on host > Engagement Tools > Find Scripts

With the above method you will find all the scripts, now you can use search functionality to find sensitive information disclosure.

4. Recon via Google Dorking:

Many times some sensitive information about a website is available on open internet. You just have to know how to find it.

Google Dorks help us to find those information efficiently, there is a whole list of dorks here Google Hacking Database (GHDB) — Google Dorks, OSINT, Recon (exploit-db.com)

Apart from the above given database, you can use readymade dork searching website like Google Hacking — Free Google Dorks for Recon — Pentest-Tools.com

5. Github Recon:

GitHub Recon is one more method to find Sensitive Information Disclosure bugs.

While writing code and working together on some projects, developers sometimes by mistake expose some sensitive data, we do GitHub recon to find and exploit these little details.

Now similarly has google dorks, there are some GitHub dorks too for recon. Here is the list of GitHub dorks: Github_recon_dorks/gitdork.txt at main · Vaidik-pandya/Github_recon_dorks

What all Data can be considered as Sensitive?

To the core, any data that leads to or affect the “Confidentiality” Factor of the CIA Triad is considered as sensitive, though depending on its sensitivity, severity is set.

But apart from these, there are some common things a hacker should always look for:

Private API Keys & Tokens:

Private API Keys are ways to access certain private resources depending on what service API key it is.

If you find an API Key do not report it without getting proper information and exploit scenario on that api key.

You can find exploit for that ap key via: https://github.com/streaak/keyhacks

2. Credentials:

There are many kinds of credentials, normal user credential, admin credentials, database credentials, security credentials, etc

But all the credentials are sensitive even though severity depends on the privileges associated with the account an attacker can access.

Disclosure of credentials like this can easily compromise that account and in case of admin credentials the whole website, which will put everything and risk and can cause huge loss.

3. PII Leakages:

Personally identifiable information (PII) is information that, when used alone or with other relevant data, can identify an individual.

PII may contain direct identifiers (e.g., passport information) that can identify a person uniquely, or quasi-identifiers (e.g., race) that can be combined with other quasi-identifiers (e.g., date of birth) to successfully recognize an individual.

Sensitive personally identifiable information can include your full name, Social Security Number, driver’s license, financial information, and medical records.

Non-sensitive personally identifiable information is easily accessible from public sources and can include your zip code, race, gender, and date of birth.

Passports contain personally identifiable information.

Social media sites may be considered non-sensitive personally identifiable information.

Why Does Information Disclosure Happen?

Information disclosure vulnerabilities can arise in countless different ways, but these can broadly be categorized as follows:

Failure to remove internal content from public content: For example, developer comments in markup are sometimes visible to users in the production environment.

Insecure configuration of the website and related technologies: For example, failing to disable debugging and diagnostic features can sometimes provide attackers with useful tools to help them obtain sensitive information. Default configurations can also leave websites vulnerable, for example, by displaying overly verbose error messages.

Flawed design and behavior of the application: For example, if a website returns distinct responses when different error states occur, this can also allow attackers to enumerate sensitive data, such as valid user credentials.

How to Mitigate/Prevent Information Disclosure Vulnerability?

Configure the web server to disallow directory listing and make sure that the web application always shows a default web page.

Sensitive data, files and any other item of information that do not need to be on the web servers should never be uploaded on the web server.

Use generic error messages as much as possible. Don’t provide attackers with clues about application behavior unnecessarily.

Make sure that all the services running on the server’s open ports do not reveal information about their builds and versions.

Do not hardcoded credentials, API keys, IP addresses, or any other sensitive information in the code, including first names and last names, not even in the form of comments.