Broken Access Control- Horizontal Privilege Escalation

PortSwigger- Broken Access Control | Horizontal Privilege Escalation

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.

1.1 carlosAPI

 

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.

2.1 Carlos UID

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.

3.1 body in 302 response

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.

4.1 administrators password

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.

Happy Pentesting!
Team CyberiumX

Scroll to Top