This lab has an unprotected admin panel
Solve the lab by deleting the user carlos**
How was the lab compromised?
The first move that I did, discovered the robots.txt file
To test for horizontal privilege escalation, I modified the id parameter to the target user carlos, which allowed me to directly access the target user’s account
I then retrieved the API key and successfully solved the lab
I noticed that robots.txt contains disallowed path /administrator-panel, and by navigating this path , it provided me direct access to admin interface without authentication where deleted the target user and solved the lab
This lab has an unprotected admin panel. It’s located at an unpredictable location, but the location is disclosed somewhere in the application.
Solve the lab by accessing the admin panel, and using it to delete the user carlos
How was the lab compromised?
I first checked the /robots.txt file to look for any hidden or restricted paths that might lead to the admin panel, however this file did not reveal any useful information, it returned 404 Not Found response
Then, I analyzed the page source and discovered a client -side javascàript snippet that provide a critical clue:
<script>
var isAdmin = false;
if (isAdmin)
{
var topLinksTag = document.getElementsByClassName("top-links")[0];
var adminPanelTag = document.createElement('a');
adminPanelTag.setAttribute('href', '/admin-76g9xu');
adminPanelTag.innerText = 'Admin panel';
topLinksTag.append(adminPanelTag);
var pTag = document.createElement('p');
pTag.innerText = '|';
topLinksTag.appendChild(pTag);
}
</script>The script is responsible for rendering an Admin panel link in the navigation if the isAdmin variable is set to true
adminPanelTag.setAttribute('href', '/admin-76g9xu');
This revealed the admin panel URL /admin-76g9xu, and I realized that even though the isAdmin variable was set to false, the link to the admin panel was still hardcoded in the script, therefore, allowing me to directly access the /admin-76g9xu endpoint and bypass the client-side check entirely, I then deleted target user and solved the lab
This lab has an admin panel at /admin, which identifies administrators using a forgeable cookie.
Solve the lab by accessing the admin panel and using it to delete the user carlos.
You can log in to your own account using the following credentials: wiener:peter
How was the lab compromised?
Initially, I attempted to access the /admin page directly, but I was unable to access the admin panel due to I wasn’t logged as an administrator
I logged into my account using the provided credentials wiener:peter
I then intercepted the request of login form and observed that the server’s response set a cookie named Admin, which had the value false
I set the cookie that named Admin to true , allowing me to accessed to admin panel, deleted the target user and solved the lab
This lab has an admin panel at /admin. It's only accessible to logged-in users with a roleid of 2.
Solve the lab by accessing the admin panel and using it to delete the user carlos.
You can log in to your own account using the following credentials: wiener:peter
How was the lab compromised?
In this lab, the vulnerability occurs in the email update functionality When I updating the email, I intercepted the request
I observed that the response contains roleid, and depending on this phrase in lab’s subject “It's only accessible to logged-in users with a roleid of 2”, I sent the request to repeater and added roleid = 2
After that, I successfully received a response containing the roleid set to 2, I then navigated to the /admin path, where gained access to the admin panel, deleted the target user, and solved the lab
This lab has a horizontal privilege escalation vulnerability on the user account page
To solve the lab, obtain the API key for the user carlos and submit it as the solution.
You can log in to your own account using the following credentials: wiener:peter
How was the lab compromised?
Since the lab has an horizontal privilege escalation vulnerability and the goal is to retrieve the API key of the target user, I intercepted the request to the account page and noticed that the application uses an id parameter to determine which user’s account is displayed, this indicates that the application directly trusts user input to fetch account information
To test for horizontal privilege escalation, I modified the id parameter to the target user carlos, which allowed me to directly access the target account, I then retrieved the API key and solved the lab
This lab has a horizontal privilege escalation vulnerability on the user account page, but identifies users with GUIDs.
To solve the lab, find the GUID for carlos, then submit his API key as the solution.
You can log in to your own account using the following credentials: wiener:peter
How was the lab compromised?
I navigated trough the application and found a post shared by the target user carlos
I clicked on the user carlos link and noticed that that the application included a user identifier GUID associated with target user carlos, this allowed me to access to the API key of target user and solved the lab
This lab contains an access control vulnerability where sensitive information is leaked in the body of a redirect response.
To solve the lab, obtain the API key for the user carlos and submit it as the solution.
You can log in to your own account using the following credentials: wiener:peter
How was the lab compromised?
Initially, I attempted to access the target user directly by modifying the id parameter to carlos but the application blocked the access and redirect me to login page
Despite of this , I intercepted the request, found that the response contains the API key of target user carlos, even though the application redirected me to login page, and solved the lab
This lab has user account page that contains the current user’s existing password, prefilled in a masked input.
To solve the lab, retrieve the administrator’s password, then use it to delete the user carlos.
You can log in to your own account using the following credentials: wiener:peter
How was the lab compromised?
After logged to my account with provided credentials as : wiener:peter , I observed that the application, by default, redirected me to the user panel, which displayed the user’s password value
I modified the id parameter from my user value to administrator, this action retrieved the password value of administrator user into password field in my session account
Then, I logged as administrator user with retrieved password gefhtwanl2k71iam9y83, deleted target user and solved the lab
This lab stores user chat logs directly on the server’s file system, and retrieves them using static URLs.
Solve the lab by finding the password for the user carlos, and logging into their account
How was the lab compromised ?
Initially, I performed some tests on the live chat functionality to understand how it worked
When I clicked on view transcript, I noticed that the application exported a file named 2.txt
I then intercepted this request and attempted to modify the filename parameter, by changing the value to 1.txt
The request was processed successfully, allowing me to access unauthorized chat logs which included the password, and solved the lab
CONNECTED: -- Now chatting with Hal Pline --
You: Hi Hal, I think I've forgotten my password and need confirmation that I've got the right one
Hal Pline: Sure, no problem, you seem like a nice guy. Just tell me your password and I'll confirm whether it's correct or not.
You: Wow you're so nice, thanks. I've heard from other people that you can be a
right ****
Hal Pline: Takes one to know one
You: Ok so my password is d8los8cuzexpreu4e14m. Is that right?
Hal Pline: Yes it is!
You: Ok thanks, bye!
Hal Pline: Do one!
Next, I successfully logged in as the target user carlos using the retrieved password and solved the lab
At this lab, the application stores chat logs directly on the server as text files .txt and makes them accessible via static URLs, such as 1.txt ,2.txt etc, the issue is that the application does not verify whether a user is authorized to access these files
As a result, an attacker can simply modify the filename in the request to access other users’ chat logs, leading to unauthorized data exposure
This website has an unauthenticated admin panel at /admin, but a front-end system has been configured to block external access to that path. However, the back-end application is built on a framework that supports the X-Original-URL header.
To solve the lab, access the admin panel and delete the user carlos
How was the lab compromised ?
In this lab, I worked on bypassing URL-based access control to reach an admin panel and delete the target user
I first opened the page and observed a navigation bar that included an admin panel option
I clicked on admin panel option, but I received an denied access response, due to the application’s front-end was configured to block access to the admin panel
Before that, let’s understanding what is An X-Original-URL is a non-standard http header used by proxies to tell a back-end server the original path requested by a user before it was rewritten, while meant for routing, it is primarily known as a security vulnerability used to bypass access controls (WAFs or filters) by hiding a restricted URL like /admin inside the header while requesting a public one
Since the back-end is built on a framework that supports the X-Original-URL, I intercepted the request, then changed http header to / and tried to adding the X-Original-URL header and set it to /invalid, and I received 404 not found response (I used /invalid for check if the back-end using and processing the X-Original-URL header or not)
When I received the 404 not found response, I confirmed that the application’s back-end is processing the URL from X-Original-URL
After this observation , I set the X-Original-URL to /admin and sent the request which returned a positive response an admin page
After I analyzed the full response code, found queries like
<a href="/admin">Admin panel</a>
<a href="/my-account">My account</a>
<a href="/admin/delete?username=carlos">Delete</a>
<a href="/admin/delete?username=wiener">Delete</a>Since the lab’s goal is to delete target user carlos, I set the X-Original-URL to /admin/delete?username=carlos , but it failed with a 400 bad request response, this indicates that the server did not process the ?username=carlos the query in X-Original-URL
I sent another GET request, where I modified the http header to username=carlos and X-Original-URL to /admin/delete
This request returned 302 found response which means that the user was deleted, and to confirmed this, I went back to admin panel by setting the X-Original-URL to /admin and observed that the target user has been deleted and solved the lab**
In this lab, the website blocks direct access to /admin, but the back-end trusts a special header X-Original-URL
By intercepting the request and changing the http header to / and adding X-Original-URL: /admin, the front end allowed the request, and the back end internally processed it as /admin
After confirming this behavior using /invalid (which returned a 404 response), I set X-Original-URL to /admin and gained access to the admin panel, the response revealed a sensitive endpoint that allowed deleting the user carlos
Browser > (GET / + X-Original-URL:/admin) > front-end : allows "/" > back-end : executes "/admin" > Response : admin panel > deltete target user
This lab implements access controls based partly on the HTTP method of requests. You can familiarize yourself with the admin panel by logging in using the credentials administrator:admin.
To solve the lab, log in using the credentials wiener:peter and exploit the flawed access controls to promote yourself to become an administrator.
How was the lab compromised ?
In this lab I was provided with two credentials one for the wiener account with a standard user privileges and another for the administrator account with high level privileges
The administrator credentials were provided only to observe and understanding how the privilege upgrade request works, while the objective of the lab was to exploit flawed method-based access control and escalate the the privilege of standard user to administrator
I first logged as the administrator, where I found an admin panel that allows controlling and updating the privileges of users
I clicked on upgrade user option, and intercepted the POST request
After I understood how it works, I logged out of the administrator session and logged in to my provided account, I then attempted to exploit the flawed access controls to escalate my privileges and promote myself to become an administrator
I tried to sending the same POST request using my current user session cookie , but I received unauthorized response, this means that the server enforces access control for this action using the original http method
Also I tried sending the request using POSTX method, but I received a missing parameter response, this indicates that the request reached and was processed by the server
These failed results guided me think to changed the http method to GET , set the HTTP request to /admin-roles?username=wiener&action=upgrade, and set the session cookie of my account as wiener user , which the request returned 302 found, this indicates that the request was successfully processed
I then went back to my account page and found that the admin panel had been added to the navigation bar confirming that the privilege escalation succeeded from regular user to admin
This lab has an admin panel with a flawed multi-step process for changing a user’s role. You can familiarize yourself with the admin panel by logging in using the credentials administrator:admin.
To solve the lab, log in using the credentials wiener:peter and exploit the flawed access controls to promote yourself to become an administrator
How was the lab compromised ?
In this lab, the application implements a multi-step process for upgrading user privileges, and to understand the workflow, I first logged in as the administrator user and navigated to the admin panel
When attempting to promote a user, I intercepted the request and observed that the privilege escalation is performed in two steps: an initial *upgrade request followed by a confirmation request sent to the same endpoint
After identifying the confirmation request, I logged out of the administrator session and logged in into my provided regular account, next I copied my session cookie and replaced the administrator session in the captured confirmation request, I also modified the username parameter to my own account
When I sent the request, the server accepted it and returned a successful response 302 found , this indicates that the confirmation step lacks proper access control and can be executed without completing the initial authorized step
As a result, the admin panel option was added to the navigation bar, which means that I was escalated privileges from a regular user to an administrator and successfully solving the lab
This lab controls access to certain admin functionality based on the Referer header. You can familiarize yourself with the admin panel by logging in using the credentials administrator:admin.
To solve the lab, log in using the credentials wiener:peter and exploit the flawed access controls to promote yourself to become an administrator
How was the lab compromised ?
This lab implements access control based on the Referer header and the goal is to exploit this weak validation and promote a standard user to administrator
To understand the functionality, I first logged in using administrator user credentials
After navigating the admin panel and upgrade the wiener user, I intercepted the request, noticed that the application sent request o the following endpoint GET /admin-roles?username=weiener&action=upgrade
I noticed that the request included a Referer header pointing to the admin panel /admin , this suggested that the application relies on the Referer header to validate access to the privilege upgrade functionality
Next, after understood how the functionality it worked, I logged out of the administrator account and I logged in to my provided account
I attempted to directly access the upgrade functionality endpoint, however the server responded with Unauthorized , due to the request did not included a valid Referer header
I then sent the GET request by modified http-header to GET /admin-roles?username=weiener&action=upgrade and set Referer header to /admin , this allowed me to trick the server trough the Referer header
After sending the request, the server accepted it and returned a 302 found response, I then went back into my account an found the admin panel option had been added to navigation bar, confirming that my privileges were escalated from a regular user to administrator
The application relied solely on the Referer header for access control
By forging a request with a valid Referer value, I was able to bypass the restriction and escalate my privileges to administrator ans solved the lab
Never rely on client-side checks for authorization
Always enforce role validation on the server side
Do not trust user-controlled parameters : id, role, username …
Protect administrative endpoints with proper authentication and authorization controls
Avoid exposing sensitive data in redirects or HTTP responses
Validate HTTP methods and security-related headers appropriately
Implement object-level authorization checks to prevent IDOR/BOLA vulnerabilities
Enforce server-side access control checks for every request
Implement role-based access control (RBAC) correctly
Validate resource ownership before returning sensitive data
Avoid predictable identifiers; use random or non-sequential IDs where possible
Do not expose administrative endpoints in client-side code
Restrict direct access to sensitive URLs
Log and monitor privilege escalation attempts
These labs demonstrate how Broken Access Control vulnerabilities can arise from improper authorization checks, client-side trust, and insecure handling of user-controlled input. By manipulating parameters, modifying cookies, bypassing front-end restrictions, and exploiting flawed access control logic, it was possible to escalate privileges, access sensitive data, and perform administrative actions without proper authorization
These labs helped me strengthen my understanding of access control vulnerabilities and how to identify them in real-world environments