Source code disclosure via backup files
This exercise was completed as part of a PortSwigger Web Security Academy lab focused on information disclosure vulnerabilities caused by exposed backup files. The purpose of the lab is to demonstrate how sensitive information can be unintentionally leaked through misconfigured web servers that expose development artifacts such as backup files and source code.
The scenario simulates a real-world web application where hidden directories are accessible over the internet and contain files that were never intended to be publicly available. These types of issues are common in misconfigured deployments where backup files are left inside web roots or where directory listing protections are not properly enforced.
The objective of the lab was to locate a backup file containing application source code, analyze it, and retrieve a hard-coded database password embedded within the code. This password would then be submitted to complete the lab.
Reconnaissance and Content Discovery
The first step in solving the lab was performing content discovery against the target application. Since the vulnerable resource was not directly linked from the user interface, directory enumeration was required to identify hidden paths.
To accomplish this, the tool dirsearch was used. This tool works by sending a large number of HTTP requests to the target, testing common directory and file names based on a wordlist. The goal is to discover endpoints that are not visible through normal browsing.
During the scan, multiple requests were sent to the application, testing for common directories such as /admin, /backup, /files, and other typical sensitive locations. This is a standard technique in web application security testing, especially when dealing with information disclosure labs.
Eventually, the scan revealed the existence of a hidden directory:
/backup
This directory was not referenced anywhere in the application, meaning it was likely unintentionally exposed and not meant for public access.
Discovering the Backup File
After identifying the /backup directory, it was accessed directly through the browser. Inside this directory, a file named:
ProductTemplate.java.bak
was found.
The .bak extension immediately indicates that this is a backup copy of a source code file. Backup files are often created automatically during development or deployment processes, or manually by developers as temporary safety copies.
In secure production environments, such files should never be placed inside directories served by a web server. However, in this case, the file was fully accessible over HTTP, meaning anyone with knowledge of its location could download it.
This represents a classic information disclosure vulnerability, where sensitive internal files are exposed due to improper server configuration.
Analyzing the Source Code
After downloading the file, the Java source code was reviewed. The file contained a class named ProductTemplate, which is part of the application's product catalog system.
The class implements serialization and includes a method called readObject, which is executed during Java object deserialization. Inside this method, the application establishes a connection to a PostgreSQL database running on localhost using port 5432.
The database connection is created using a ConnectionBuilder, and it includes several hard-coded configuration values such as:
-
Database user:
postgres -
Host:
localhost -
Port:
5432 -
Database name:
postgres - Password: hard-coded in source code
The most critical finding in this file was the database password:
diro2fuzix4e30z7z2cfi58rott5bmn5
This credential is embedded directly into the application source code, which is a significant security flaw. Hard-coded credentials are dangerous because they are often reused, difficult to rotate, and can be exposed unintentionally when source code is leaked.
Security Issues Identified
The lab demonstrates two major security problems that often appear together in real-world applications:
1. Exposed Backup Files
The presence of the /backup directory allowed direct access to sensitive files that should never be publicly accessible. Backup files often contain:
- Source code
- Configuration files
- Development notes
- Sensitive credentials
When such files are exposed, attackers gain insight into the internal structure of the application.
2. Hard-Coded Credentials in Source Code
The second issue is the use of hard-coded database credentials inside the application code. This is considered insecure because:
- Credentials are exposed if source code is leaked
- They cannot be easily rotated
- They are often reused across environments
- They increase the impact of any information disclosure vulnerability
In this case, the combination of exposed backup files and embedded credentials made it trivial to retrieve the database password.
Exploitation and Lab Completion
The exploitation process was straightforward once the vulnerability was identified:
- Directory enumeration was performed using dirsearch
-
The
/backupdirectory was discovered -
The file
ProductTemplate.java.bakwas accessed directly - The source code was downloaded and analyzed locally
- The database connection logic was reviewed
-
The hard-coded password was extracted:
diro2fuzix4e30z7z2cfi58rott5bmn5 - The password was submitted as the solution to complete the lab
This represents a typical information disclosure exploitation chain, where reconnaissance directly leads to sensitive data extraction.
Key Takeaways
This lab highlights a very common real-world issue in web application security: exposure of backup files and source code in publicly accessible directories.
Even though this is a controlled training environment, the same vulnerability pattern appears frequently in real applications due to poor deployment practices.
The main lessons from this exercise include:
- Never store backup files inside web-accessible directories
-
Always remove
.bak,.old, and similar files from production environments - Avoid hard-coding credentials in source code
- Regularly perform content discovery to detect exposed files
- Assume attackers will actively search for hidden resources
Conclusion
This PortSwigger lab demonstrates how a simple misconfiguration can lead to full exposure of sensitive information. Through basic directory enumeration using dirsearch, a hidden backup directory was identified, leading to the discovery of source code containing a hard-coded database password.
Although this is a lab environment, the same vulnerability pattern is highly relevant in real-world web applications and highlights the importance of secure file handling and proper deployment hygiene.
Comments