Labs Covered
This write-up focuses on the following PRACTITIONER-level labs from the PortSwigger Web Security Academy:
10 URL-based access control can be circumvented
This lab demonstrates how attackers can bypass access control by directly accessing restricted URLs without proper authorization checks.
11 Method-based access control can be circumvented
This lab highlights how restricting access based on HTTP methods (e.g., GET, POST) can be ineffective if the server fails to enforce proper authorization on all methods.
12 Multi-step process with no access control on one step
This lab shows how incomplete access control checks on multi-step processes can allow attackers to bypass certain steps and perform unauthorized actions.
13 Referer-based access control
This lab illustrates the weakness of relying on the `Referer` header for access control, which can be easily manipulated by attackers to gain unauthorized access.
LAB 10 - URL-based access control can be circumvented
Lab Description :
Overview
1. X-Original-URL
This header indicates the original request URL before any modifications were applied by intermediate systems (such as proxies or load balancers). It can be compared to a note attached to a package during shipping, specifying the initial delivery address.
2. X-Rewrite-URL
This header reflects the rewritten or updated URL after the request has been modified by intermediaries. Continuing with the shipping analogy, this is like adding a new note to the package indicating that the delivery address has changed due to some decision or rule.
Analogy Example:
Imagine you order a package online:
- The original delivery address (your home address) represents the
X-Original-URL. - If the delivery company changes the address (e.g., redirects it to a nearby pick-up center), the new address represents the
X-Rewrite-URL.
Solution :
When the lab website loads, we immediately see the Admin panel link present.
When we click it, we get Access Denied.
We capture the request in Burp. It looks like:
Actual request -
Modified request
- Add the
X-Original-Url: /admin/deleteheader - Provide the
username=carlosparameter as it is in the real query string.
LAB 11 - Method-based access control can be circumvented
Lab Decription :
Solution :
.
This lab provides the administrator credentials to analyse the workflow of granting and revoking administrative permissions to users. It basically is just a form to select a user and using an Upgrade or Downgrade button:
Our goal is to exploit the flawed access controls to promote ourself (wiener) to become an administrator.
Log in using an admin account, then access the admin panel to promote the user [Normal].
So we can try to perform the role changing action as wiener by pasting the cookie value of wiener in the request made by admin to change the privileges.
So we change the cookie value of admin with wiener & send the request, we get the response as 401 - Unauthorized
Response:
Since this lab is based on Method-Based-Access control bypass, we can try to change the request from POST to GET. We can do this by Right click on request -> Click Change request method option.
Now it changes to a GET request,
Response:
Response displays 302** Found with directory location **/admin*, which means the URL function has successfully upgraded the user with username wiener to admin.
There is an admin panel that shows the wiener account has been promoted to admin.
LAB 12 - Multi-step process with no access control on one step
Lab Description :
)
Solution :
Mostly developers implement strong acces controls in the first step but fail to ensure it in the subsequent steps , so we can take advantage of that to perform privilege escalation.
After loging as administrator we can see below page
Once logged in , we can go to admin panel & modify other user’s privileges.
We need to upgrade wiener as admin by flawed multistep process, so lets now poke around with wiener.
We get a 401 unauthorized error.
If we try to upgrade ourself (wiener) by changing the cookie value of admin to non admin in the request of first step , with the confirmed parameter:
We get a redirection and then an 302 response with admin access:
So Now the admin panel is accessible for wiener now:
Thus we solved the lab ,
LAB 13 - Referer-based access control
Lab Description :
Solution:
The process to upgrade the user is generated from the admin panel with a GET request:
But with “carlos” we get an unauthorized error:
It works chaning the “Referer” header to /admin and username to carlos.
Thus we solved the lab by upgrading ourselves(wiener) to higher privilege.