Broken access control

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

Hello folks,
This blog focuses on the identification and exploitation of “Horizontal Privilege Escalation”, which is a type of Broken Access Control vulnerability. If you want to know more about Broken Access Control and another type of it called vertical privilege escalation, you can read our earlier blog post titled “Vertical Access Control”.
We will be providing a detailed walkthrough of PortSwigger’s labs which you can access on its website. Now, let’s look at horizontal access control and see how attackers can misuse it through horizontal privilege escalation before we move on.
Horizontal Access Control is a protective measure designed to restrict an account user’s access to critical resources or features owned by other users at the same (horizontal) permission level. Let’s understand the same using an example. In a file-sharing platform, each user should exclusively have the ability to access or edit their documents, rather than those of other account users who share the same privileges. This principle guarantees that users can only interact with data or operations that have been explicitly authorized for their account, thereby maintaining confidentiality and system integrity.
Horizontal Privilege Escalation happens when an account user accesses resources that belong to another user at the same privilege level, instead of only their resources. For instance, if a user can access and change the profiles of another user who has similar access rights, rather than just their profile.

Lab-1 User ID controlled by request parameter

In this scenario, we will understand how we can access the information of another existing user on the website by predicting the user ID and then providing it to any request parameter. We can read the lab description and click “Access the lab”. This lab can be performed without Burp Suite as well.
To log in as wiener user, we have to click on the “My account” button which will bring the login page. After logging in, we will find that a GET parameter is available on the URL called id, which takes the username as a value. We know the username of our target user which we can provide here to access its API key. Let’s replace the username with carlos and send the request. We will find that we are now able to access the profile details of carlos user where we have the API key available. We can submit carlos’s API key as an answer and solve the lab.

Lab-2 User ID controlled by request parameter, with unpredictable user IDs

The user IDs can be made unpredictable using globally unique identifiers (GUIDs) which are very lengthy. The attacker can still find the GUID value of the victim user if it is exposed somewhere within the website. We can read the lab description and click “Access the lab”. This lab can be performed without Burp Suite as well.
To log in as wiener user, we have to click on the “My account” button which will bring the login page. After logging in, we will find that there is a GET parameter available on the URL called id where the GUID value is mentioned. Now we cannot predict the GUID value of carlos user, so we have to find it within the website. Let’s go to the home page and start exploring the available blogs. We have to find a blog written by carlos user to get the GUID value of his account.

Right-click on carlos, select “Copy link address” and then paste the URL on the new browser tab. Finally, we will see the account page of carlos user. We can submit carlos’s API key as an answer and solve the lab.

Lab-3 User ID controlled by request parameter with data leakage in redirect

Some web applications can identify horizontal privilege escalation and try to redirect the attacker to the login page but within the redirect request, some sensitive information related to the webpage that the attacker was trying to access can be found. In this situation, the attacker can still access the contents of some user’s data. We can read the lab description and click “Access the lab”. This lab requires the Burp Suite community edition.
To log in as wiener user, we have to click on the “My account” button which will bring the login page. After logging in, we will find that a GET parameter is available on the URL called id, which takes the username as a value. We know the username of our target user which we can provide here to access its API key. Let’s replace the username with carlos and send the request. We will find that we are redirected to the login page but if we check the same request on Burp Suite, we will see a body with a 302 response which is a misconfiguration. If we check the response we will find the profile details of carlos user including the API key.

We can submit carlos’s API key as an answer and solve the lab.

Lab-4 User ID controlled by request parameter with password disclosure

After changing the request parameter for accessing the profile of any user, if we can access the functionality/profile of the administrator/admin user, it can lead to Vertical Privilege Escalation. We can read the lab description and click “Access the lab”. This lab can be performed without Burp Suite as well.
To log in as wiener user, we have to click on the “My account” button which will bring the login page. After logging in, we will find that a GET parameter is available on the URL called id, which takes the username as a value. Also, on the webpage, we will find the password for the wiener user. We can convert the password into clear text by pressing Ctrl+Shift+I and searching for “password” within the HTML code. Double-click on “type=password” and replace “password” with “text”. We will see the password of the wiener in clear text. In the same way, we can try to access the password of the administrator user by replacing the value of the id parameter with “administrator” and then convert the password to clear text using Inspect.

Finally using the password we can log in as administrator and access the “Admin panel”. To solve the lab, delete the carlos user.

In this blog, we learned how to identify and exploit Horizontal Privilege Escalation, another type of Broken Access Control vulnerability. In the upcoming blog, we will explore other ways to identify and exploit Broken Access Control.
You can check out our other web application penetration testing blogs on our website.