Hello folks,
This blog focuses on the identification and exploitation of Broken Access Control vulnerability. We will be providing a detailed walkthrough of PortSwigger’s labs which you can access on the PortSwigger website.
This blog post is about other ways to identify and exploit Broken Access Control vulnerabilities. If you want to know more about Broken Access Control and its type, you can read our earlier blog posts titled “Vertical Access Control” and “Horizontal Access Control“.
Lab-1 Insecure direct object references
In this scenario, we will understand another type of Broken Access Control, which is called Insecure Direct Object References (IDOR). This vulnerability occurs when an attacker directly refers to an object like a profile, documents, etc. of other users and gets access to it. We can read the lab description and click ‘Access the lab’. This lab requires the Burp Suite Community edition.
On the home page, we will find a “Live chat” functionality where we can chat with a live assistant and resolve our problems. While using Burp Suite as a proxy, let’s interact with the assistant. We can download our chats by clicking on the “View Transcript” button. As we click on it, we will see that a file is downloaded with the name “2.txt”.
If we open the file we will see our chat history. Now we know what is IDOR, so we can try to access a file with the name “1.txt” and see if we can access it. Let’s switch to Burp Suite and under “HTTP History”, we will find a GET request that allows us to download our chat history. We need to take this request to Repeater and change the file name to “1.txt”. As we send this request, we will find the chat history of some other user. If we read the chat history, we will see that the user is requesting to get his/her current password.
We know that if we need to solve the lab, we require the password of carlos user so that we can login. Let’s copy the password and go to the login page where we can use carlos as a username and then paste the password. We will find that we have successfully accessed the account of carlos user and hence the lab is solved.
Lab-2 Multi-step process with no access control on one-step
In this scenario, we will understand how broken access control can be performed in a multi-step process where the strong access control is applied on other steps except one. We can read the lab description and click ‘Access the lab’. This lab requires the Burp Suite Community edition.
In this lab we are provided with the credentials of the administrator user so let’s login using it and proxy the traffic through Burp Suite. After logging in we need to access the “Admin panel” where we will find a functionality to upgrade/downgrade a user. Let’s upgrade carlos user to see how the functionality works. We will find a review page after submitting the request to upgrade carlos user where we need to confirm the same.
After confirming, we will find that the user has been upgraded successfully. Let’s logout from the administrator account and login as wiener user. On the “HTTP History” tab of Burp Suite, we will find two POST requests; one for the first step where we submitted the request to upgrade carlos user, and the other one to review to same. Let’s take both requests to a repeater and try to change the username to wiener and replace the administrator’s session cookie with wiener’s cookie. If we send the first request, we will find an unauthorized message in the response, but if we send the second request, we will see a 302 redirection response which confirms that the wiener’s account is upgraded to an admin account.
Now we can access the admin panel from the wiener’s account. Hence the lab is solved.
Lab-3 Referer-based access control
Certain websites utilize access controls that rely on the Referer header included in the HTTP requests. This header is added by user browsers and confirms from where a particular request is generated. This header helps the server to establish access control. We can read the lab description and click ‘Access the lab’. This lab requires the Burp Suite Community edition.
In this lab, we are provided with the credentials of the administrator user so let’s login using it and proxy the traffic through Burp Suite. After logging in we need to access the “Admin panel” where we will find a functionality to upgrade/downgrade a user. Let’s upgrade carlos user to see how the functionality works. As we submit the request, we will find that carlos is upgraded to an admin role.
Let’s logout from the administrator account and login as wiener user. On the “HTTP History” tab of Burp Suite, we will find a GET request where we have two URL parameters.
Let’s take this request to repeater and change the username to wiener and replace the administrator’s session cookie with wiener’s cookie. Now if we check the request carefully, we will find a Referer header within the HTTP request header which might be used to manage access control. If we try to remove the referer header from the request, we will find an unauthorized response. But if we add the referer header back, then the request is accepted.
Wiener’s account has been upgraded to an admin role. Hence the lab is solved.
This is all we need to know while identifying and exploiting Broken Access Control vulnerabilities on web applications. We explored all categories of this vulnerability.
You can check out our other web application penetration testing blogs on our website.
Happy Pentesting!
Team CyberiumX