Imagine that your friend Bob creates a website, and you and Alice create an account on the website out of love and care for your friend. The website implements role-based features, meaning that Bob is the admin and can add, delete, modify products, and delete users who act maliciously. On the other hand, you and Alice have a user role and can only view the products and add them to your cart for further checkout.

But tinkering around with the web application, you realize that you can view Alice’s cart.

Because I can view Alice’s cart despite the fact that I do not have access, this is referred to as the Broken Access Control.

Before we move on to the vulnerability, let’s discuss what access controls are and why they are used.

Access control, also called Authorization, applies restraints or constraints on who can perform what action. These can be role-based or resource-based. For example, in the case of our hypothetical website, neither Alice nor you should be able to delete each other’s accounts or view each other’s carts.

But since you could view Alice’s cart, this is an instance of Broken Access Control.

Broken Access control can occur due to various reasons. Some of them are:

1. When the application is misconfigured.

Instead of designing an application from the ground up, developers nowadays rely on frameworks to assist them in decreasing their workload and making their jobs more efficient. However, it is frequently the case that the developer does not fully comprehend the dynamics of the framework and hence misconfigures it throughout the deployment process. Whether a framework is being used or making mistakes while configuring a website is quite easy if you aren’t clear about the user roles. If the user roles are not defined appropriately or if they have excessive permission, this will occur regardless of what is displayed on the user interface. It will cause an access control issue with the application because the roles have been misconfigured, and a couple of users may be able to access resources they are not supposed to access.

2. Unprotected Functionality

A user’s access to administrative functions should always be restricted. The default functionality of an application, or misconfiguration issues, might sometimes result in a user being able to fuzz the URL endpoint to gain access to the admin functions. However, this is not always the case. This commonly occurs when the admin endpoints do not have access control configured, and they grant access to each and every user without completing any authorization checks on their access requests.

3. Storing user info in hidden fields, cookies, and parameters.

After the user logs into their account, the web server provides the user with a one-of-a-kind value. This one-of-a-kind value can be used to access the user’s account. There are several places where this information might be stored, including an invisible field on the web page, a cookie, or even URL parameters. Examples include specific applications assigning the username or a numeric user id in a cookie or hidden field that is being used to retrieve the resources, resulting in no proper authorization of the material and access being provided solely based on the username or user id assigned by the application.

Because they are on the client’s end, they are not tamper-proof by default. Any user with sufficient expertise can tamper with the values and acquire access to the account of any other user by changing them. He can brute force the user id to find out how many user ids have been assigned by the application, or he can fuzz the username endpoint to find out how many valid usernames have been assigned.

This type of broken access occurs when the application provides direct access to the objects before even running a permission check. As a result, we can take the same e-commerce application into consideration. You are assigned the user id 121, while Alice is assigned the user id 122. As soon as you log into the application, you are redirected to the dashboard, with the following URL: https://myhopytheticalsite.com/user/dashboard/?id=121.

Note, the id parameter. It is set to 121, which maps to you. Now just out of curiosity you try to change it to 122 and whoosh, you are presented with Alice’s dashboard. This in general is called Insecure Direct Object Reference and falls under the category of Broken Access Control.

This can also be implemented by the use of cookies, and hidden fields.

The e-commerce web application was just used as an illustration. When it comes to real-world consequences, they can be far more severe than in theory. Some of the most prevalent effects of a broken access control system vary depending on the application type:

1. Horizontal Privilege Escalation

This is when you are able to view or modify sensitive information of other users. The scenario we discussed was of Horizontal Privilege Escalation. The personal sensitive information may contain PII data such as Name, email address, Credit Card Numbers and other sensitive information such as API keys. So due to this it is considered as a Severe vulnerability.

2. Vertical Privilege Escalation

This occurs when a member is able to assume the role of an admin. For exampleIn the event that a normal user is directly capable of performing operations that are normally performed by an administrator, such as adding users, changing their privileges, and so on. As a result, he has the ability to remove the administrator or steal important information such as billing information, among other things.

Example Case Scenario

pstmt.setString(1, request.getParameter("4231"));
 ResultSet results = pstmt.executeQuery( );

The following data is used by the application in a SQL request that is attempting to retrieve account information:

An attacker only needs to modify the browser’s ‘acct’ value in order to send whatever account number they like. If the attacker’s credentials are not adequately checked, he or she can gain access to any user’s account.

https://example.com/app/accountInfo?acct=4244

Remediation

Broken Access Controls are very common to find in web apps implementing role-based functionalities. It is so common that it holds the first position in the OWASP TOP 10 List, 2021.

Some of the steps that a developer can take are:

1. Model access controls should enforce record ownership rather than accepting that the user can create, read, update, or delete any record.
2. Deny a sensitive resource by default, until it is required to be accessible to the public.
3. Log Access Control failures, wherever an attempt is made by any user.
4. Apply rate limiting on all API endpoints.
5. Properly implement CORS.
6. Try to implement a single mechanism to implement access-controls.