Access Control | https://portswigger.net
What is access control?
Access control is the application of constraints on who or what is authorized to perform actions or access resources. In the context of web applications, access control is dependent on authentication and session management:
In this session, we will be going through some of the common access control Vulnerabilities and solve the labs from https://portswigger.net/
1. Horizontal Privilege Escalation Vulnerability
This lab contains a user ID that is controlled by request parameter with unpredictable user id.
To solve the lab, we are required to 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
Accessing the lab, we are presented by a blog page where we are required to identify the blog post made by carlos.
Lets fire up our burp suite and intercept the http request with carlos blog here we can see carlos user id as shown below.
user id: = 4d0b96a9–29ba-4962-ade8-a456aacb9809
We proceed to login with wieners credentials as given. wiener:peter
When we intercept the request from wieners account, we get his user id on burp as well as his API key is displayed on the website.
Should we change the account id, we should be able to get carlos API’s key and submit to solve the lab.
Vertical Privilege Escalation | Unprotected Functionality
If a user can gain access to functionality that they are not permitted to access then this is vertical privilege escalation. For example, if a non-administrative user can gain access to an admin page where they can delete user accounts, then this is vertical privilege escalation.
At its most basic, vertical privilege escalation arises where an application does not enforce any protection for sensitive functionality. For example, administrative functions might be linked from an administrator’s welcome page but not from a user’s welcome page. However, a user might be able to access the administrative functions by browsing to the relevant admin URL. For example, a website might host sensitive functionality at the following URL:
https://insecure-website.com/admin
https://insecure-website.com/robots.txt
This lab has an unprotected admin panel. Solve the lab by deleting the user Carlos.
Lets start by accessing the /robots.txt to access the hidden contents.
https://0a71003f034c7bfd808aad8b001e003d.web-security-academy.net/robots.txt
Access /administrator-panel and delete the contents.
Unprotected Functionality | Unprotected admin functionality with unpredictable URL
In some cases, sensitive functionality is concealed by giving it a less predictable URL. This is an example of so-called “security by obscurity”. However, hiding sensitive functionality does not provide effective access control because users might discover the obfuscated URL in a number of ways.
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 carols.
Since we are looking for a hidden directory with /admin we will start by exploring the page ‘View Source ’ and look for an unusual admin link.
Proceed to delete the carlos user and you will have solved the lab.
Parameter-Based Access Control Methods | User role controlled by request parameter
Some applications determine the user’s access rights or role at login, and then store this information in a user-controllable location. This could be:
A hidden field.
A cookie.
A preset query string parameter.
The application makes 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 insecure because a user can modify the value and access functionality they’re not authorized to, such as administrative functions.
The 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
Once logged in, you can change the value admin=false to admin=true from burp suite inspector tab and send the request.
When everything is done correctly, you should be able to delete carlos profile by visiting the path
/admin/delete?username=carlos
User role can be modified in user profile
In this lab, we are required to access the administrators panel and delete the user carlos.
we start by accessing our own account with the credentials wiener:peter
Once logged in, try to update your email and capture the request to burp and notice a json parameter in the request with the value of your email and the response contains an interesting parameter which is the role id.
Add the roleid to the request in a json format.
You can bruteforce with intruder and notice that only roleid 1 & 2 result in a 302 response.
Change the role id to 2 and send the request.
Copy the response to your broswer and notice that you are now logged in as an admin, you can delete carlos account.
User ID controlled by request parameter, with unpredictable user IDs
This lab has a horizontal privilege escalation vulnerability on the user account page, but identifies users with GUIDs.
To solve the lab, we will submit Carlos API key. We can use the logins wiener:peter
Start by logging in
Notice you are assigned an API Key so now we need to get other users APIs, specifically Carlos.
Visit his blog post and check for any interesting details from the proxy requests.
Notice that the refferer header leaks his user id, which we can replace to our own id to get to his profile.
We have the admins API KEY.
Look for carlos blog post and repeat the steps above to obtain his Api Key.
User ID controlled by request parameter with data leakage in redirect
This lab is rather the easiest.
To solve the lab, we need to submit carlos Api key which is leaked in the body of a redirect response.
Once you are logged in as wiener, check for Api in the response body.
Simply change the username from wiener to carlos in the repeater and forward the response.
Check in the redirect message for carlos API..
Submit the solution and you will have solved the lab.
Lab: User ID controlled by request parameter with password disclosure
In this lab, we are required to login as administrator and delete the user Carlos account.
Log in with the credentials wiener:peter.
Notice that in the my account page, you can update the password and the email. In the response, the password is visible in a form input. This in itself is a bad practice.
Try changing your user from wiener to that of administrator.
Log in with the password in the input form and delete the user carlos.
Lab: Insecure direct object references
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.
The live chat contains a view transcript that refers to our chat history with the bot. So we can try to access the chats of other users via the same.
Change the name extension from /2.txt to /1.txt.
Looks like we obtained carlos password easily from the response.
Lab: URL-based access control can be circumvented
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.
First access to the lab, we see an Admin panel, which is access is denied when we try to visit.
Notice that when you bruteforce for headers using param miner extention in burp, you get no results. This is because the
X-ORIGINAL-URL & THE X-REWRITE-URLare custom non-standard http headers that can be used to override urls in the original requests. These headers usually help to bypass front server rules, which are based on URI, but you don’t change URI while using these headers.
A 403 response can be bypassed by adding these headers as explained by https://github.com/sting8k/BurpSuite_403Bypasser/issues/4
So in our lab, we will add the non-standard header. Either the x-rewrite-url or the x-original url to point to the path /admin.
We access the admin panel, however we cannot access the users so we try the x-original-url
We can follow the path to delete carlos user as follows.
