PortSwigger Academy: Information Disclosure

Introduction

Information disclosure rarely compromises a system on its own, but it’s almost always a step in the chain. A stack trace tells us what framework to attack. A debug page reveals which environment variables exist. A leftover .git/ exposes the entire source history.

In this post, I’ll walk through five labs from PortSwigger Academy’s Information Disclosure module, each showing a different way an app leaks data and how that leak turns into a real attack.

Lab Overview

Lab	Difficulty	Vulnerability
Lab 1	APPRENTICE	Verbose error messages
Lab 2	APPRENTICE	Debug page exposure
Lab 3	APPRENTICE	Backup file disclosure
Lab 4	APPRENTICE	HTTP method misconfiguration
Lab 5	PRACTITIONER	Git repository exposure

---

Lab 1: Information disclosure in error messages

APPRENTICE View lab on PortSwigger →

This lab's verbose error messages reveal that it is using a vulnerable version of a third-party framework. To solve the lab, obtain and submit the version number of this framework.

Solution:

1. I started by running a crawl scan in Burp (without audit). I right-clicked the target in Site map → New scan → Crawl. Configuring crawl scan

2. Once it finished, the dashboard showed several endpoints with query parameters like /product?productId=2. Endpoints with query parameters

3. I sent the request to Repeater and triggered an error by adding ':

   GET /product?productId=2' HTTP/2
   Host: [lab-id].web-security-academy.net
   

   This returned a 500 Internal Server Error with a stack trace revealing Apache Struts 2 2.3.31. Version disclosure in error message

4. I submitted 2 2.3.31 as the flag. Lab solved.

Lab 2: Information disclosure on debug page

APPRENTICE View lab on PortSwigger →

This lab contains a debug page that discloses sensitive information about the application. To solve the lab, obtain and submit the SECRET_KEY environment variable.

Solution:

1. Another crawl scan revealed /cgi-bin/phpinfo.php. Debug page exposed

2. The page contained SECRET_KEY in PHP Variables $_SERVER['SECRET_KEY'] with value zxnk4qzn64okinervdce8v9r7inwnjd3. Environment variable exposed

3. I submitted the secret key as the flag. Lab solved.

Lab 3: Source code disclosure via backup files

APPRENTICE View lab on PortSwigger →

This lab leaks its source code via backup files in a hidden directory. To solve the lab, identify and submit the database password, which is hard-coded in the leaked source code.

Solution:

1. Another crawl scan discovered robots.txt, /backup, and /backup/ProductTemplate.java.bak. Backup directory discovered

2. Contents of robots.txt:

   User-agent: *
   Disallow: /backup
   

   The crawler found /backup from this file.

3. I accessed /backup and saw a directory listing with ProductTemplate.java.bak. Backup file exposed

4. I found a hardcoded password in /backup/ProductTemplate.java.bak: 966yj4yg30h7wcte4dnyskc73xuolkpj. Database password in source code

5. I submitted the password as the flag. Lab solved.

Lab 4: Authentication bypass via information disclosure

APPRENTICE View lab on PortSwigger →

This lab's administration interface has an authentication bypass vulnerability, but it is impractical to exploit without knowledge of a custom HTTP header used by the front-end.

To solve the lab, obtain the header name then use it to bypass the lab's authentication. Access the admin interface and delete the user carlos.

You can log in to your own account using the following credentials: wiener:peter.

Tip: When credentials are provided, use them to focus on the intended solution. Admin pages in PortSwigger Academy are typically at /admin.

Solution:

1. I logged in as wiener:peter.

2. I accessed /admin and got 401 Unauthorized. Admin panel inaccessible

3. In Repeater, I changed the method to TRACE:

   TRACE /admin HTTP/2
   Host: [lab-id].web-security-academy.net
   Cookie: session=ZakynhQJxmlM8wjYyoEHTL8krx6cS7vD
   

   The response revealed header X-Custom-IP-Authorization: 114.10.45.25: Custom header exposed via TRACE

4. I assumed the application validates IP based on this header and whitelists localhost (127.0.0.1), so I tried:

   GET /admin HTTP/2
   Host: [lab-id].web-security-academy.net
   Cookie: session=ZakynhQJxmlM8wjYyoEHTL8krx6cS7vD
   X-Custom-Ip-Authorization: 127.0.0.1
   

   Successfully bypassed! Successfully accessed admin panel

5. I accessed /admin/delete?username=carlos to delete user carlos:

   GET /admin/delete?username=carlos HTTP/2
   Host: [lab-id].web-security-academy.net
   Cookie: session=ZakynhQJxmlM8wjYyoEHTL8krx6cS7vD
   X-Custom-Ip-Authorization: 127.0.0.1
   

   User carlos deleted successfully Lab solved.

Info: The TRACE method is an HTTP debugging feature that echoes back the exact request received by the server, including all headers. This can expose internal headers added by proxies or load balancers. When enabled, attackers can discover custom authentication headers or other security-related information not visible in normal requests. Learn more: WSTG-CONF-06, Acunetix - HTTP Security, TRACE Method Vulnerability.

Lab 5: Information disclosure in version control history

PRACTITIONER View lab on PortSwigger →

This lab discloses sensitive information via its version control history. To solve the lab, obtain the password for the administrator user then log in and delete the user carlos.

Solution:

1. Burp’s crawler returned nothing this time, so I used dirsearch for fuzzing:

   dirsearch -u https://[lab-id].web-security-academy.net/
   

   I found /.git/! Git directory exposed

2. I used git-dumper to download the repository:

   git-dumper https://[lab-id].web-security-academy.net/.git ./output
   

3. For analyzing commit history, I used tig:

   sudo apt install tig
   cd output
   tig .
   

   Git commit history In commit 716e35def03ce384f44fc9e180be7faad73e6698, file admin.conf originally contained:

   ADMIN_PASSWORD=qdp530wezwrw81wkut0z
   

   Then changed to:

   ADMIN_PASSWORD=env('ADMIN_PASSWORD')
   

4. I logged in as administrator:qdp530wezwrw81wkut0z and deleted user carlos. Lab solved.

Conclusion

We’ve covered five different ways an application leaks information: verbose errors, debug pages, backup files, HTTP TRACE, and exposed git history. None of these directly compromise the system, but each one hands an attacker a piece of the chain leading to authentication bypass or credential exposure.

The fix for each is straightforward: silence verbose errors, remove debug endpoints, lock down backup files, disable TRACE, and keep version control out of the web root.