Portswigger Labs
Last updated
Last updated
This website has an unprotected admin panel. Visiting /robots.txt shows me this:
I can access this and delete the carlos user, which solves the lab.
Same thing as Lab 1, just that the panel is located at a random directory.
Checking the page source reveals this randomised directory:
It's still unprotected, so deleting carlos is trivial.
Logging in, I see that there is an Admin cookie set to false.
Changing this to true allows me to view the /admin panel.
To solve the lab, just send a GET request to /admin/delete?username=carlos.
Loggin in, I see that there is an update email function. When testing it, I can see that a roleid parameter is returned in the response:
The POST request sends a JSON object with the email parameter. I added a roleid parameter and it worked:
This allows me to access the /admin panel to delete carlos.
This lab requires horizontal privilege escalation, and I have to obtain the API key of carlos.
Logging in, I see that the /my-account directory uses an id parameter with the username:
Changing wiener to carlos allows me to view his account:
Same as Lab 5, just that the ID isn't as predictable. When viewing blog posts, I can see a few by carlos:
I noticed that the blogs posted by carlos contain a different user ID in the URL:
Visiting /my-account?id=213bd623-d8a5-4374-8161-fc52861f3bcc would show us the API key.
This lab uses a plain username as the id parameter. When visiting carlos, it attempts to redirect me to the login page:
However, this does not change the fact that the user profile is still loaded.
Logging in, I can see that there's a password change feature, with the user's password already typed in:
This value is present in the page source:
Visiting carlos profile via changing the id parameter results in his password being displayed:
Change the id to administrator, visit their profile and read the password.
Then, login and delete carlos.
This lab has a live chat feature:
When using the 'View transcript' function, I can see that 2.txt is downloaded:
Changing this to 1.txt shows me the password of carlos:
Attempting to visit the unauthenticated admin panel results in an 'Access denied' being returned:
This lab supports using the X-Original-URL header. This header overrides the target URL in requests with the one specified in this header value.
This means that although I cannot visit /admin directly, I can do so via using X-Original-URL:
I can then solve the lab by specifying /admin/delete within this header, which would override the target URL of /. The username parameter can be written in the target URL.
To solve this lab, make wiener an administrator. This lab also gives us admin access straightaway.
The admin panel has a function to change user privileges.
This thing sends a POST request to /admin-roles with a username and action parameter. action is either set to 'upgrade' or 'downgrade'.
When I logged in as wiener and attempted to send the same POST request, I got a 403 Unauthorized.
Changing it to a GET request solves the lab:
This lab highlights the fact that it just takes 1 mistake for access control to be completely broken. To solve, make wiener the admin from a unprivileged account.
I upgraded carlos to administrator, and there was a confirmation page:
I noticed that replaying this request with the session cookie of wiener did not work. However, sending a 'Yes' confirmation (by including confirmation=true within the POST parameters) bypasses the authorisation check:
This lab controls access based on the Referer header. When vistiing the admin panel, I noticed the header:
To solve, just send the GET request used to upgrade a user to admin with the Referer header set:
Remember to change the Cookie value to the wiener cookie.
