Information Disclosure

Information disclosure (also called Information Leakage) is a vulnerability where a system unintentionally reveals sensitive data to unauthorized users. This leaked information may not directly compromise a system, but it can provide significant data for an attacker to plan further attacks.

Such vulnerabilities often occur due to poor configuration, unhandled errors, verbose responses, or insecure storage/transmission of data, and can provide data about other users, usernames, or financial information, sensitive commercial or business data, technical details about the website and its infrastructure.

Common types of Information Disclosure are:

  • Detailed server or application errors that reveal software versions, file paths, database queries, and stack traces, or hint at their existence

  • Directory listing is enabled in the web server configuration, allowing anyone to browse files and directories

  • Sensitive files exposed, such as .env files, information on robots.txt, config backups, source code archives, or logs that are publicly accessible

  • Version disclosure in HTTP headers, code, or page comments that reveal framework, CMS, or server versions

  • Hard-coded API keys, IP addresses, and database credentials

  • Metadata Leaks, where files like images, PDFs, and documents may contain author names, geolocation, or internal paths

  • Exposed APIs and debug endpoints, which return extra data supposed to be only viewed by developers

  • Insecure Third-Party Integrations, where services like analytics or monitoring tools leak internal IDs or API keys through requests

  • Cloud Storage misconfiguration that allows public read access

  • Verbose API Responses returning unnecessary JSON fields like user hashes, internal IDs, or privilege levels

Scope

Information Disclosure is primarily a server-side vulnerability, though in some cases it can have some client-side elements.

On the server-side, most occurrences come from the backend, unintentionally revealing sensitive data, and since the server controls and transmits this data, the vulnerability originates in server logic, configuration, or access controls.

On the client-side, there are certain scenarios, such as sensitive data stored insecurely in browser storage (localStorage, sessionStorage, IndexedDB) or embedded within the front-end source code.

Overall, the scope spans any point where sensitive data is made accessible to unauthorized parties, whether due to insecure backend handling or insecure frontend storage.

Exploitation Techniques

It's important not to miss anything that could be useful later. You will often find sensitive data while testing for something else. A key skill is being able to recognize interesting information whenever and wherever it comes

Leaks on Webcrawler Files

The majority of sites offer files like robots.txt and sitemap.xml to rules for web crawlers to navigate a site. These files could contain sensitive information or reveal sensitive routes

  • Check if these files are exposed and contain sensitive information

http://$URL/robots.txt # If improperly configured, could contain secret routes

# This could contain something like this
User-agent: *
Disallow: /administration-panel # Hidden route

Exposed .htaccess and .htpasswd Files

The .htaccess and .htpasswd are configuration files used by Apache web servers. The first file mentioned is used to control directory-level settings, define access rules, enable or disable features, and implement security measures, and the second file is used to store hashed passwords used for basic authentication, allowing for restricted access to certain resources.

In some cases, the access permissions to these files aren't properly set. Here we can find how to leverage this misconfiguration:

  • Check if these files are exposed and don't have any access restrictions

http://$URL/.htaccess    # If properly configured, we should get a 403 error code
http://$URL/.htpasswd    # If not, it would be possible to leak their contents

  • Also, after gaining access as the user from a web server, it's possible to explore the default folder for servers /var/www/html and look at the hidden files to search for them

cd /var/www/html
ls -a    #The response could contain the desired files

Fuzzing

We can use tools such as Gobuster, ffuz, and Feroxbuster to automate the process of directory and file discovery and find routes with directory listing enabled. In the same way, we can use the Burp Suite Intruder tab.

If you identify interesting parameters, you can try submitting unexpected data types and specially crafted fuzz strings to see what effect this has.

This could help us to easily identify differences in responses by comparing HTTP status codes, response times, lengths, and so on.

We can also use the Logger++ Burp Suite extension, which, in addition to logging requests and responses from all Burp Suite tools, allows advanced filters to be defined to highlight interesting entries or filter logs to only those that match the filter.

Study Error Messages

The use of verbose error messages can lead to Information Disclosure of details such as software versions, file paths, database queries, among others.

It can reveal information about what input or data type is expected, provide information about different technologies being used, the version number of those technologies, and dangerous default settings that you may be able to exploit.

  • We can try to provoke an error on purpose to obtain information from the error message

http://example.com/item?id=1 # We could change this value
http://example.com/item?id=h #As intended to be a number, could provoke an error

Leaks in Debugging Data/Routes

For debugging purposes, many websites have custom routes, error messages, and logs that contain large amounts of information about the application's behavior. These could contain values for key session variables, hostnames, credentials, file and directory names on the server, keys used to encrypt data transmitted via the client, among others.

  • We can try to search for debugging routes in source code comments or access standard debug files

http://example.com/debug-mode # This route could be found on a code comment
http://example.com/cgi-bin/phpinfo.php # This is a standard debug file for PHP

Source Code Disclosure

Obtaining source code helps to understand the application's behavior and construct other attacks. Sensitive data is sometimes even hard-coded within the source code.

Also, when open-source technology is being used, it provides easy access to a part of the source code, or even when using other utilities that generate temporary backup files.

  • We could search for backup files or folders exposed

http://example.com/backup # It could have directory listing enabled and some files
http://example.com/backups # Another common option

It's even possible to cause the website to expose its source code in cases where it is being executed rather than simply sending it to the client as text.

  • We could trick a website by appending a ~ to the filename (indicates it is a temporary file, common on text editors) or adding a different extension, such as a backup file extension

http://example.com/index.php # This will be directly executed
http://example.com/index.php~ # But this could return the source code
http://example.com/index.php.bak # Or even this

Disclosure via HTTP TRACE Method Misconfiguration

The HTTP TRACE method is designed for diagnostic purposes, and if it is enabled, the web server will respond to requests with this method by echoing in the response the exact request that was received. This could occasionally leak internal authentication headers that may be appended to requests by reverse proxies.

  • For example, we found an endpoint that seems to be sensitive, but we are not authorized

Original Request
GET /admin HTTP/2
Host: example.com
Original Response
HTTP/2 401 Unauthorized
Content-Type: text/html; charset=utf-8
X-Frame-Options: SAMEORIGIN

  • We use the TRACE method and observe that it returns a custom header

TRACE Request
TRACE /admin HTTP/2
Host: example.com
TRACE Response
HTTP/2 200 OK
Content-Type: message/http
X-Frame-Options: SAMEORIGIN

TRACE /admin HTTP/1.1
Content-Type: text/html; charset=utf-8
X-Frame-Options: SAMEORIGIN
X-Custom-Auth: 256.0.256.0

  • Now we can add the header in any request with 127.0.0.1 to indicate a local route to the server, and we will now be authorized

Modified Request
GET /admin HTTP/2
Host: example.com
X-Custom-Auth: 127.0.0.1
New Response
HTTP/2 200 OK
Content-Type: text/html; charset=utf-8
X-Frame-Options: SAMEORIGIN

In cases like this, we can go to Proxy > Match and replace on Burp Suite to automate the sending of the header in every request

Exposed Version Control History

Websites are usually developed using a version control system, such as Git. By default, a Git project stores all of its version control data in a .git folder that could be exposed if misconfigured.

We can browse to this site (which is inefficient most of the time), or use tools such as Git-Dumper or GitSniff to download the entire folder and gain access to the website's version control history, which may include logs containing committed changes and other interesting information.

Impact

It can have both a direct and indirect impact depending on the purpose of the website and, therefore, what information an attacker can obtain, which in the wrong hands could be the key information required to construct other exploits. The attackers can use leaked data for:

  • Reconnaissance understanding technology stack and architecture

  • Privilege Escalation exploiting known version vulnerabilities

  • Credential Theft using leaked passwords, tokens, or keys

  • Social Engineering using employee names and internal talking

Information disclosure is not a high-severity issue on its own, but the severity is in the demonstration of how an attacker could do something harmful with it.

Mitigation Strategies

It could be complicated due to the huge variety of ways in which it can occur, but some general best practices are:

  • Awareness of what information is considered sensitive and/or can be much more useful to an attacker, protecting sensitive files with proper permissions, or moving them outside the web root

  • Audit any code for potential information disclosure as part of your QA of the build processes, implementing automated tasks

  • Use generic error messages as much as possible to avoid providing any clues about the application behavior

  • Double-check that any debugging or diagnostic features are disabled in the production environment

  • Understand the configuration settings and security implications of any third-party technology implemented

  • Turn off directory listing on web servers and sanitize HTTP headers to avoid version exposure

  • Use Content Security Policy (CSP) to restrict resource access

  • Regular security audits for API endpoints and cloud storage

Checklist for Developers and Sysadmins

PreviousBroken Access ControlNextPath Traversal

Last updated