Labs Covered
This write-up focuses on the following APPRENTICE-level labs from the PortSwigger Web Security Academy:
1 Unprotected admin functionality
This lab demonstrates how administrative functionality can be exposed without proper access controls, allowing unauthorized users to access sensitive areas of the application.
2 Unprotected admin functionality with unpredictable URL
This lab highlights how security through obscurity (using unpredictable URLs) is insufficient if proper authentication and authorization controls are not enforced.
3 User role controlled by request parameter
This lab illustrates how manipulating request parameters that control user roles can lead to privilege escalation and unauthorized access.
4 User role can be modified in user profile
This lab shows how insecure user profile management can allow users to modify their own roles, potentially gaining administrative privileges.
5 User ID controlled by request parameter
This lab demonstrates insecure direct object reference (IDOR) vulnerabilities where user identifiers in requests can be manipulated to access other users’ data.
6 User ID controlled by request parameter, with unpredictable user IDs
This lab extends the IDOR concept by introducing non-sequential, unpredictable user IDs that still lack proper authorization checks.
7 User ID controlled by request parameter with data leakage in redirect
This lab shows how sensitive information can be leaked via redirects when user input is not properly validated or sanitized.
8 User ID controlled by request parameter with password disclosure
This lab demonstrates how manipulating request parameters can lead to exposure of password information for other users.
9 Insecure direct object references
This lab emphasizes the importance of implementing proper access controls to prevent unauthorized access to internal resources based on user-supplied object references.
LAB 1 - Unprotected admin functionality
Lab Description :
Solution :
When the lab loads, a standard shopping website interface is displayed. Selecting the My Account option redirects the user to the /login endpoint, indicating that authentication is required to access this section.
The next objective is to bypass the login page and gain direct access to the admin interface. To achieve this, we can investigate commonly exposed web directories, such as robots.txt and sitemap.xml, which may disclose hidden or sensitive endpoints.
robots.txt
We see a disallowed login entry here for the admin panel which is /administrator-panel.
On visiting the /administrator-panel directory, we get the admin panel.
So we click the link to delete the user carlos to solve the lab.
LAB 2 - Unprotected admin functionality with unpredictable UR
Lab Description :
Solution :
The lab webpage looks like this,
Clicking on My Account, takes us to the Login page at /login.
By clicking Control+u we can read the source code and find the admin panel.
So we could directly browse to that directory to view the admin panel.
Click on ther DELETE link of carlos to delete the carlos user .Thus lab is solved.
LAB 3 - User role controlled by request parameter
Lab Description :
Solution :
Some applications determine the user’s access rights or role at login, and then store this information in a user-controllable location, such as a hidden field, cookie, or preset query string parameter. The application makes subsequent access control decisions based on the submitted value. For example:
- https://insecure-website.com/login/home.jsp?admin=true
- https://insecure-website.com/login/home.jsp?role=1
This approach is fundamentally insecure because a user can simply modify the value and gain access to functionality to which they are not authorized, such as administrative functions.
Steps -
We have our login page,
In the lab description , it is given that the admin page is at /admin. Lets try visiting that page.
It says we can view only if we are admin!
We have a login credential wiener:peter .Lets try logging in and see what requests & responses being made.
Once we hit login after entering username and password, it sends a POST request like this,
Then a GET request is made to retreive the /myaccount page .
Here we have an interesting cookie - Admin=false.
The reponse looks like this ,
We are logged in as wiener
What happens if we change the cookie value to Admin=true ?
We modify all the requests where the cookie is set to Admin=false to Admin=true`
POST req to /login endpoint
GET req to /myaccount endpoint
GET req to /admin endpoint
After getting the myaccount page, we click the Admin panel link, the request sent is modified as follows
Atlast, we get the admin panel .
Now we can delete the suer carlos and solve the lab.
GET req to /admin/delete endpoint
Capture the request to delete the user carlos & change the cookie value here too!
We have sucessfully solved the lab.
LAB 4 - User role can be modified in user profile
Lab Description :
Solution :
So as per the lab description, we can view the admin panel only if our roleID=2.
Login page -
Enter the credentials which are given for testing which is wiener:peter& click LOGIN button,
Noticed the ‘My account’ section and observed the update email feature.
Till now we didn’t see any suspicious cookie values being sent from our client
Lets move on & try to update our email.
Request :
Send the request to repeater (I tried sending all the previous requests to repeater, it didn’t have the roleid cookie either in request or response)
Response :
Observe that we have a roleid=1 in the JSON response.
So add the value roleid=2 in the JSON request & see what is the response in browser
We have a 302 redirect
Click Follow redirect,
Now we can see the link to Admin Panel in the browser.
Now click on admin panel & delete the carlos user to solve the lab.
LAB 5 - User ID controlled by request parameter
Lab Description :
Solution :
When ther lab loads , we see the usual shopping website. Clicking on My account takes us to a login page.
We enter the credentials which is given in the lab description - wiener:peter
When we login we get to see the API key of wiener - T9VQGi3yf81cho2IzdP5jN61hT9zc1YA
To solve the lab , we need to retreive the API key of carlos user.
When we click on My Account after loggin in as wiener, a request is sent like this
It contains ?id=wiener parameter.
Change the value to ?id=carlos, we get the API key of carlos and thus solved the lab
LAB 6 - User ID controlled by request parameter, with unpredictable user IDs
Lab Description :
Solution :
In some applications, the exploitable parameter does not have a predictable value. For example, instead of an incrementing number, an application might use globally unique identifiers (GUIDs) to identify users. Here, an attacker might be unable to guess or predict the identifier for another user. However, the GUIDs belonging to other users might be disclosed elsewhere in the application where users are referenced, such as user messages or reviews.
Click on My Account , it takes us to login page. Use the credentials wiener:peter to login.
Once we login, we can see the API key of wiener.
Click on My Account & capture the request.
We have the GUID of wiener in the request. We need to somehow find the GUID of carlos to get his API key.
For that , click on the home page and browse through all the blog posts by carlos, Click on his username
Now we got the GUID of carlos - 0cae1b22-401e-46b4-b767-09e89441403a
GUID of wiener - jrrAYctrKLzzPUvGA7eKyh9NmlO6SPzm
GUID of carlos - 0cae1b22-401e-46b4-b767-09e89441403a
Now in the My Account page , click on the link , capture the request and modify the GUID of wiener with carlos to get the API key.
In the response now we get the API key of carlos - 9FLbgOm1kRjJoisnIuYN51HHtQdtOwYZ
Thus we solved the lab.
LAB 7 - User ID controlled by request parameter with data leakage in redirect
Lab Description :
Solution :
In some cases, an application does detect when the user is not permitted to access the resource, and returns a redirect to the login page. However, the response containing the redirect might still include some sensitive data belonging to the targeted user, so the attack is still successful.
Clicking on My Account takes us to the login page where we can login as wiener useing the credentials wiener:peter.
We get the account page which displays wiener’s API key - C9CMxZRxQVICJFNdYKDPrmiKSY5NxbMG
When we click on My account again, the browser sends a request which contains ?id=wiener
GET /my-account?id=wiener HTTP/2
Host: redacted
Cookie: session=Ues4LJi6ijUdDxBu151S7lxWUznAJ8SH
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:106.0) Gecko/20100101 Firefox/106.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: redacted/my-account
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Te: trailers
Send the request to repeater tab. Change the value to ?id=carlos and observe the response.
We get a 302 Redirect response back .
HTTP/2 302 Found
Location: /login
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
X-Frame-Options: SAMEORIGIN
Content-Length: 3395
Here the API key of Carlos is leaked in the redirect response.
API key of wiener - C9CMxZRxQVICJFNdYKDPrmiKSY5NxbMG
API key of carlos - M8XFUdMj MOWODYF4vovFWYLGzbot2KVX
Submit the key and the lab is solved.
LAB 8 - User ID controlled by request parameter with password disclosure
Lab Description :
Solution :
The account page that contains the current user’s existing password, prefilled in a masked input. So lets login as wiener to see what the account page has.
We can see there is a pre filled password in the password field. We can’t see the password in plaintext but we can try reloading the page / view source-code to see what the password is.
So the password is prefilled with the password of the user winer which we logged in.
Now if we click on the My account link again after logging in , the page reloads where it sends a request as below.
Change the parameter ?id=wiener to ?id=administrator.
Thus we have sucessfully exploited it as it leaked the admin’s password in the response.
Password - nrmwf5x1228f0spbcvxt
Now we can login as admin & delete user carlos to solve the lab.
LAB 9 - Isecure direct object references
Lab Description :
Solution :
The lab page contains a Live chat link which allows us to send messages and also view transcripts,
For testing, first I tried to send a message.
Now when I click transcript, it disconnects from the chat and downloads the chat transcript.
Notice that The transcript downloaded was 2.txt and why not 1.txt?. Maybe there was previous chats which contains carlos’s password
As we guessed, the first chat 1.txt contains the chat which has carlos’s password.
Now login as carlos, to solve the lab.