PortSwigger Lab Write-up: Information Disclosure Vulnerabilities
I’m Subhadip Sardar, a cybersecurity enthusiast with a strong foundation in IT and cybersecurity. I’m passionate about sharing knowledge and empowering the community to build safer digital environments. Currently, I’m creating an in-depth guide to the Information Disclosure vulnerability and solving practical labs from PortSwigger, designed to help others understand and defend against common web security threats. Join me as we explore the world of cybersecurity.
What is Information Disclosure?
Information disclosure, or information leakage, happens when a website unintentionally shares sensitive information with users or attackers. This can include:
- Data about other users, such as usernames, emails, or financial information.
- Sensitive business or commercial information.
- Technical details about the website’s infrastructure, like server versions, database information, or error messages.
Even though leaking user or business data is clearly risky, leaking technical information can be just as dangerous. While some of this technical data might not seem important, it can give attackers clues that help them find more serious vulnerabilities. This information can sometimes be the missing piece they need to launch a larger, more damaging attack.
Sometimes, sensitive information might accidentally appear to regular users while browsing the website. However, attackers often provoke this leakage by interacting with the site in unusual or harmful ways, then analyzing the site’s responses to find any hidden details.
Examples of information disclosure
Some basic examples of information disclosure are as follows:
- Revealing the names of hidden directories, their structure, and their contents via a
robots.txtfile or directory listing - Providing access to source code files via temporary backups
- Explicitly mentioning database table or column names in error messages
- Unnecessarily exposing highly sensitive information, such as credit card details
- Hard-coding API keys, IP addresses, database credentials, and so on in the source code
- Hinting at the existence or absence of resources, usernames, and so on via subtle differences in application behavior
Some common causes of information disclosure vulnerabilities
Information disclosure vulnerabilities happen when a website unintentionally reveals sensitive information. This can happen in several ways:
- Leaving Internal Information in Public Content: Sometimes, developers leave comments or other internal details in the website’s code. If these aren’t removed before the site goes live, users (including attackers) can see this information, which might give clues about the site’s structure or security weaknesses.
- Insecure Configuration: Websites can be set up incorrectly. For example, if debugging tools or detailed error messages are left enabled on a live site, they can give attackers hints about the website’s inner workings. Using default settings without changing them can also expose too much information.
- Design Flaws: If a website behaves differently when various errors happen (like showing different messages for wrong usernames versus wrong passwords), attackers can use this to figure out valid usernames or other details they shouldn’t have access to.
These issues can make it easier for attackers to gather useful information, leading to potential breaches or other attacks.
Impact of information disclosure vulnerabilities
Information disclosure vulnerabilities can have serious consequences, depending on the type of information leaked and the context in which it happens.
- Direct Impact: If sensitive data like customer credit card details, personal information, or passwords are exposed, the consequences can be severe. This can lead to financial loss, identity theft, and a loss of trust in the affected website.
- Indirect Impact: Sometimes, less obvious information like a website’s directory structure, software versions, or third-party frameworks used may be leaked. While this might not seem harmful at first, attackers can use this technical information to find weaknesses and launch other attacks, like exploiting known vulnerabilities in the software mentioned.
How to assess the severity of information disclosure vulnerabilities
Assessing the severity of information disclosure vulnerabilities involves understanding how the disclosed information can be used by an attacker. Not all information leaks are equally dangerous; the context and potential impact determine their severity.
For example, if a website reveals it’s using a specific version of a software framework, this may not be a serious issue if that version is up-to-date and patched. However, if the version is outdated and has known security flaws, an attacker could use this information to exploit the site easily with existing exploits.
When you find information being leaked, it’s crucial to think about how this information could be used maliciously. If it’s just minor technical details, it may not be a big deal. But if the leaked information can lead to serious attacks or if the information itself is highly sensitive (like user passwords or personal data), then it becomes a significant issue.
So, the focus should be on how harmful the disclosed information can be, not just the fact that some information is leaked. The more sensitive or exploitable the information, the more severe the vulnerability.
How to test for information disclosure vulnerabilities?
Testing for information disclosure vulnerabilities involves identifying and examining areas where sensitive data might be inadvertently exposed. This can include web applications, APIs, server configurations, error messages, and more. Here are some guides on hoe to test for information disclosure vulnerabilities:
- Identify Areas to Test
- Web pages: Check for comments in the HTML, hidden fields, URLs, and JavaScript files.
- Error Messages: Review error messages for sensitive information.
- HTTP Headers: Inspect HTTP headers for server details.
- APIs: Test API responses for unintended data exposure.
- Backup and Temp files: Search for backup files, temporary files, or version control files left on the server (e.g., ‘.bak’, ‘.tmp’, ‘.git’, etc).
- Configuration files: Look for misconfigured or expose configuration files that might contain sensitive information (e.g., ‘config.php’, ‘.env’, etc).
2. Manual Testing
- View Source: Check the source code of web pages for comments or hidden fields that might contain sensitive information.
- Error Messages: Intentionally trigger errors to see if stack traces, SQL queries, or other sensitive information is revealed.
- URL Manipulation: Alter URL parameters to see if unauthorized data can be accessed.
- Directory Browsing: Attempt to access directories directly to check if directory listing is enabled.
- API Responses: Make API calls with various parameters to see if sensitive data is returned.
3. Automated Scanning
- Web Application Scanners: Use tools like OWASP ZAP, Burp Suite, or Nikto to automate the discovery of information disclosure vulnerabilities.
- File and Directory Brute forcing: Use tools like DirBuster, Gobuster, or FFUF to brute force directories and file names.
Common Tools for Testing Information Disclosure
- Burp Suite: For intercepting requests, manipulating parameters, and analyzing responses.
- OWASP ZAP: For automated scanning and manual testing.
- Nikto: For web server scanning.
- DirBuster/Gobuster: For directory and file brute-forcing.
- Nmap: For network scanning and service enumeration.
- curl/Wget: For HTTP requests and response inspection.
Common sources of information disclosure
Information disclosure can occur in a wide variety of contexts within a website. The following are some common examples of places where you can look to see if sensitive information is exposed.
1. Files for web crawlers
Information disclosure happens when a website unintentionally reveals sensitive data. One common place to check for such leaks is in files meant for web crawlers, like robots.txt and sitemap.xml.
robots.txt: This file guides search engines on which parts of the website to skip or not index. Sometimes, it lists directories containing sensitive information, which shouldn't be public.sitemap.xml: This file helps search engines map out the structure of the site, showing all the URLs. It can sometimes reveal hidden or sensitive pages that shouldn't be easily accessible.
These files are typically not linked from the main website pages, so they may not appear in standard site scans. However, you can manually check them by visiting https://example.com/robots.txt or https://example.com/sitemap.xml to see if they expose any useful or sensitive information.
2.Directory Listings
When a web server is set up to show the contents of a folder that doesn’t have an index page (like index.html), it can automatically display a list of all the files and subfolders in that directory. This feature is called directory listing.
While directory listing might not seem harmful at first, it can give attackers an easy way to see what files are stored in that folder. They can quickly find important files and focus their efforts on exploiting them. This becomes a bigger problem if the directory contains sensitive files like temporary files, backup files, or crash reports that shouldn’t be publicly accessible.
By itself, directory listing isn’t necessarily a security flaw. But if a website also lacks proper security measures to restrict access to sensitive files, directory listing can reveal information that should be hidden, increasing the risk of an attack.
3. Developer comments
When developers are working on a website, they often add in-line comments in the HTML code to remind themselves or others about certain things. These comments are usually removed before the website goes live. However, sometimes they are forgotten or left in by mistake. Even though these comments aren’t visible on the website itself, they can still be seen by anyone who looks at the website’s code using the browser’s developer tools.
The problem is that these comments can sometimes contain sensitive information that could help an attacker. For example, the comments might mention hidden files or directories, or give clues about how the website works. This information can make it easier for an attacker to find vulnerabilities and exploit the website.
4. Error messages
Information disclosure happens when sensitive details about a website or its systems are unintentionally revealed. One of the most common ways this occurs is through error messages. Error messages can give away valuable clues that attackers can use to exploit the website. For example, a detailed error message might tell you exactly what type of data or input the system is expecting from a user, which can help in crafting a more targeted attack. It could also expose which technologies, like the database type, programming language, or even the server version, are being used on the website.
This kind of information is useful because if you know the version of the server or database, you can search online for known security flaws specific to that version. Additionally, error messages can reveal information about open-source frameworks that the website may be using, allowing attackers to look up the publicly available code and find potential weaknesses.
Sometimes, differences in how error messages appear can also reveal how the application behaves behind the scenes. For example, subtle variations in error messages could help attackers figure out things like valid usernames or if certain parameters are vulnerable to SQL injection attacks. Therefore, it’s important to be cautious about what error messages reveal, as they can provide attackers with critical information to exploit the system.
Practical: Information disclosure in error messages
With Burp running, open one of the product pages and intercept the request in Burp Suite.
Next, go to Burp Suite and Send the intercepted request to Burp Repeater.
In Burp Repeater, change the value of the productId parameter to a non-integer data type, such as a string. Send the request:
GET /product?productId="example"The unexpected data type causes an exception, and a full stack trace is displayed in the response. This reveals that the lab is using Apache Struts 2 2.3.31.
Go back to the lab, click “Submit solution”, and enter 2 2.3.31 to solve the lab.
5. Debugging data
During development, developers use debugging messages to help track and fix issues in the code. These messages contain valuable information about how the application works, which can be helpful for improving the system. However, if this information is accidentally exposed in a live (production) environment, it can be very dangerous.
For example, these debug messages might show things like session variables, which are used to track users’ activities, or even sensitive details such as backend credentials, file paths, and encryption keys. If attackers manage to access these debug logs, they could gain insight into the system’s structure and find weaknesses to exploit. This could give them the ability to craft specific inputs to manipulate the application or access restricted areas.
Practical: Information disclosure on debug page
With Burp running, browse to the home page.
Go to Burp Suite, go to the Target → Site Map tab. Right-click on the top-level entry for the lab and select Engagement tools → click on Find comments.
Notice that the home page contains an HTML comment that contains a link called Debug. This points to /cgi-bin/phpinfo.php.
In the site map, right-click on the entry for /cgi-bin/phpinfo.php and send the request to Repeater.
In Burp Repeater, send the request to retrieve the file. Notice that it reveals various debugging information, including the SECRET_KEY environment variable.
Go back to the lab home page, click on Submit solution, and enter the SECRET_KEY to solve the lab.
6. User account pages
Information disclosure happens when sensitive data is exposed unintentionally on a website. One common place where this can occur is on user account pages. These pages often hold important details like email addresses, phone numbers, and API keys. Normally, a user can only access their own account information, which by itself isn’t a problem.
Get SubhaDip’s stories in your inbox
Join Medium for free to get updates from this writer.
However, issues arise when there are flaws in the website’s logic that can be exploited. For example, let’s say a website loads a user’s account page based on a URL parameter like this:
GET /user/personal-info?user=johnWhile the website might prevent attackers from changing this parameter to access other users’ entire account pages, the security measures might not extend to all the individual pieces of data on that page.
Imagine if the website checks to load the whole page correctly but doesn’t check as strictly when pulling specific details, like the email address. An attacker could then change the user parameter in the URL and potentially display another user's email address on their own page, even though they can't see the entire account page.
7. Source code disclosure via backup files
Information disclosure happens when sensitive details of a website, like source code or hidden data, become exposed to users or attackers. This can happen in various ways, but one common scenario involves the accidental exposure of source code through backup files or misconfigurations.
Imagine the source code as the blueprint of a website, detailing how it works behind the scenes. If an attacker gets hold of this blueprint, they can more easily understand the website’s inner workings and find ways to exploit it. Sometimes, this source code even contains sensitive information like API keys or passwords, which should never be exposed.
Now, even if a website uses well-known open-source technology, an attacker already has some access to its general structure and functionalities through publicly available source code. However, the real risk comes when they can see the specific implementation of the website, especially if it includes custom code or sensitive details.
In some situations, websites might accidentally reveal their own source code. For example, web servers are designed to execute code files, like PHP files, rather than show their contents directly to users. But if the website isn’t properly configured, or if there are backup files left on the server, attackers might find a way to trick the server into displaying the code as plain text.
A common trick attackers use involves temporary backup files, which are often created by text editors when files are being edited. These backup files might have a different name or extension, like a tilde (~) at the end or a .bak extension. If an attacker guesses the name of these backup files and requests them, they could see the actual source code in the response.
Once the attacker gets access to this source code, they have a significant advantage. They can spot hidden vulnerabilities or weaknesses that would be much harder to find without this insider knowledge. This is why protecting the source code and avoiding accidental disclosures is crucial for a website’s security.
Practical: Source code disclosure via backup files
Open lab home page and browse to /robots.txt and notice that it reveals the existence of a /backup directory.
Browse to /backup to find the file ProductTemplate.java.bak.
Now, With Burp running, browse to the page.
Next, right-click on the lab in the site map and go to Engagement tools → click on Discover content.
Then, launch a content discovery session to discover the /backup directory and its contents.
Browse to /backup/ProductTemplate.java.bak to access the source code.
In the source code, notice that the connection builder contains the hard-coded password for a Postgres database.
Go back to the lab, click Submit solution, and enter the database password to solve the lab.
8. Information disclosure due to insecure configuration
One common issue is insecure configuration, which means the website or its components are not set up properly, leading to vulnerabilities. This often happens because many websites rely on third-party tools or frameworks that have numerous settings. Sometimes, the people who set up these tools may not fully understand all the options, which can result in unsafe configurations.
Another typical mistake is when developers leave debugging features turned on in the live, public version of the website. For example, the HTTP TRACE method is used to help with troubleshooting. If this feature is left active, the web server might send back the exact request it received, including any internal data, in its response. While this may seem harmless, it can sometimes leak sensitive information like internal headers used for authentication, which could give attackers clues about how the system works or allow them to mimic legitimate requests.
Practical: Authentication bypass via information disclosure
Go to lab home page then click on My account and log in to your username and password: wiener:peter
After login now try to browse the /adminpage and notice that the response discloses that the admin panel is only accessible if logged in as an administrator, or if requested from a local IP.
Now intercept this request and send it to Burp Repeater.
Go to Repeater and send the request again, but this time use the TRACE method:
TRACE /admin
Study the response. Notice that the X-Custom-IP-Authorization header, containing your IP address, was automatically appended to your request. This is used to determine whether or not the request came from the localhost IP address.
Now, go to Settings → Proxy → Match and replace.
Under HTTP match and replace rules, click Add. The Add match/replace rule dialog opens.
Leave the Match field empty. Under Type, make sure that Request header is selected. In the Replace field, enter the following:
X-Custom-IP-Authorization: 127.0.0.1Click on ok.
Under Auto-modified request, notice that Burp has added the X-Custom-IP-Authorization header to the modified request.
Burp Proxy now adds the X-Custom-IP-Authorization header to every request you send.
Browse to the home page. Notice that you now have access to the admin panel, where you can delete carlos.
9. Version control history
Information disclosure can happen when sensitive details about a website are accidentally made accessible to users or attackers. One common source of such information is the version control history, which websites often use during development.
Most websites use tools like Git for version control, which helps track changes in the website’s code. Git stores this data in a hidden folder called .git. Sometimes, developers accidentally expose this folder on live websites. If this happens, an attacker can access it just by navigating to /.git on the website.
While it might be tough to read the raw contents of the .git folder manually, attackers can download the entire folder and open it using Git on their computers. This allows them to see the website's change history, including logs of updates and code snippets.
Even if attackers don’t get the complete source code, the bits of code they can access may reveal sensitive information, such as passwords or keys, that was hard-coded in previous versions of the website.
Practical: Information disclosure in version control history
Open any item from the site.
The lab is about version control information disclosure, so I added ‘.git’ on the path and I found this:
I downloaded this folder with wget –mirror command:
Now I change into that directory, check the git log and find an interesting commit message in the last commit:
So I move my working directory back to the commit before that:
A quick directory listing shows an interesting file with even more interesting content:
Now it is simply logging in with administrator:fhu2iuqjk0zp7aevh7oh and accessing the Admin panel:
After I delete user carlos, and solve the lab.
Mitigation Strategies of information disclosure vulnerabilities
Mitigating information disclosure vulnerabilities involves several key strategies to ensure sensitive data remains protected. First, access controls like the principle of least privilege and role-based access control help restrict data access to only those who need it. Encrypting data both at rest and in transit protects it from being read by unauthorized parties. Input validation prevents attackers from injecting malicious code to expose data.
Error handling should be designed to show generic messages to users while logging detailed errors securely for internal use. Keeping systems updated and disabling unnecessary services reduces the attack surface. Security headers, like Content-Security-Policy, prevent common exploits such as cross-site scripting.
Masking sensitive information in logs and interfaces prevents it from being accidentally revealed. Firewalls and intrusion detection systems block suspicious network activity, while network segmentation keeps sensitive data isolated from less secure areas. Regular security testing, such as vulnerability scans and penetration tests, helps identify and fix potential issues early.
Secure development practices, including following coding guidelines and conducting code reviews, minimize the introduction of vulnerabilities. Finally, training for developers, administrators, and users on security best practices raises awareness and reduces the risk of human error leading to data leaks.
I hope you enjoyed this write-up! Thank You! Happy Hacking :)
Follow to me on Medium and be sure to turn on email notifications so you never miss out on my latest informative posts.
Follow me on below Social Media:
- LinkedIn: Subhadip Sardar
- Twitter | X : @Mr_SubhaDip03
- GitHub : SubhaDip003
- Check My TryHackMe Profile : TryHackMe | SubhaDip
