Techniques for securing the Web with the Access Control Model

Techniques for securing the Web with the Access Control Model

24 | 07 November 2021 18:32 | Security | Ditulis oleh Arif Rahman Wahid

So far you may have come across various web applications where you can invite members with limited access to information within the organization. developers can build those apps or services by implementing the Access Control Model in their apps.

What is Access Control Model

The Access Control Model is to control user access to resources and how they interact with them. In the context of a web application, the Access Control Model is used to control user access to resources and how they interact with them. For example, if a user is an administrator, he or she may be allowed to access all the resources in the application. However, if the user is a member, he or she may only be allowed to access very specific resources in the application.

In the following Role-Based Access Control Model example, you can see it has 3 different roles defined with different set of permissions assigned to each role, For example, admin role has access to All(users, Documents, logs, and Reports) in Organization but manager only have access to users, documents and reports when the user role is further restricted and only allowed to access users and documents within the organization.

  • Let's dig deeper to find out the different types of Access Control Models implemented in our everyday applications:
  • Role-Based access controls(RBAC): This model assigns access rights to users based on the work they do in an organization. In this Access Control Model, administrators can assign users to one or more roles according to their work tasks. Each role allows access to specific resources
  • Discretionary Access Control (DAC): In this type of access control permissions are granted or restricted based on access policies defined by the owner of the organization or asset.
  • Mandatory Access Control (MAC): This model allows grouping of resources according to the sensitivity model. This model is mainly found in military or government environments where it can be understood in groups such as confidential, secret, top-secret etc.

Broken Access Control Model

As we are well aware of the fact that web applications have grown much more complex and large in terms of handling and processing information. so it undoubtedly increases the complexity in the implementation of the secure and perfect Access Control Model in this application.

Access Control Model that allows users with limited permissions in the organization to access restricted information within the organization is considered corrupt and flawed. That's where the term Broken Access Control was born. And whatever is broken it paves the way for EVIL HACKER to exploit it.

Error occurred

You might ask what problems can arise if the Access Control Model is not implemented properly? and what are the implications if those issues are exploited in real world scenarios? The answer is quite simple, whenever the permissions model fails to implement properly, the possibility of privilege escalation arises in the system and the extent of the attack will depend on which part of the system or application is affected or exposed. users/roles.

Now, Back to our question what can go wrong when implementing the Access Control Model. During my experience there are 3 different possibilities:

  • Permissions not implemented properly In this case some are exposed to unauthorized roles/users without the required Permissions applied properly to them, For example if /api/users is required Permission read:users, attacker will be able to browse /api/users without Permission read :users.
  • Permission X override Permission Y: In this case if a user is granted the read:users Permission to access the /api/user API Endpoint, he is also automatically granted access to the /api/reports endpoint. So, we can say Permission read:users overrides read:reports.
  • Set of Permission override Permission X : In this case, if a user is granted read:users and Permission read:reports to access /api/user and /api/reports API, he is also automatically granted access to /api/files, Please note that random combination of Permission leads to Permission problem here, So in this case, we can say random combination of Permission read:W read:X and read:Y allows read:Z access too.

Now, the real challenge is to build a penetratin testing methodology that covers all of these scenarios and gives full coverage of the target model. To do that, we design different techniques for each type of scenario that can occur in the system. Which finally brings us to a technique called the following.

testing Access Control Model is Broken

My favorite part is where I will lay out various techniques and strategies for testing broken Access Control Models in applications. With several years of experience as a pentester and analyzing BACM(broken access control models), we have come up with several effective techniques for pentesting Access Control Models.

Our three main effective techniques/approaches are as follows:

  • Forwards Approach
  • PBackword Approach
  • Mixed Approach

To understand this approach effectively, let's assume we're pentesting a web application (by implementing the Access Control Model) that allows us as admins to invite users into our organization with custom Permissions. Permissions are depicted in the image below along with the accessible APIs. It should be clear that users with Permissions only will be able to access related APIs adjacent to them. If in any way he can access other APIs, the Access Control Model will be considered broken.

Access-Control-Model

Forward Approach

In the Forward Approach strategy, the user should be invited with only one permission (say the permission is green first) and then the invited user with only one permission will try to access all the other restricted APIs sequentially. After completing the first tester case, the user should be invited with the 2nd permission and will then try to access all the other restricted APIs sequentially and so on.

Some of the test cases generated by the Forward Approach are listed below:

Example Forward Approach 1:

In the following Forward Approach case, the user is granted the read:users permission in the model and then he tries to access another restricted API in the model permissions.

Access-Control-Model

Example Forward Approach 2:

In the following Forward Approach case, the user is granted write:users permissions in the model and then he tries to access other restricted APIs in the model permissions.

Access-Control-Model

Example Forward Approach 3:

In the following Forward Approach case, the user is granted the read:documents permission in the model and then he tries to access another restricted API in the model permissions.

Access-Control-Model

Backword Approach:

In the Backword Approach, the user must be granted all permissions in the model except one permission and we will try to access the respective API from the permissions without permission.

Example of Backword Approach 1:

In the following Backword Approach case, user is granted all permissions except read:user permission in the model and then it tries to access user information from GET /api/users as shown in below screenshot.

Access-Control-Model

Example of Backword Approach 2:

In the following Backword Approach case, the user is granted all permissions except write:users permission in the model and then it tries to change the user information from the POST point /api/users which has no permissions.

Access-Control-Model

Mixed Approach

In the Mixed Approach, the user must be invited with a mixed set of permissions from the permission list and then he will try to access the corresponding API point from the restricted role.

Example of Mixed Approach 1:

In the following Mixed Approach case, the user is granted read:users, write:docs, write:logs permissions then all other restricted API points should be tested against these mixed permissions to check for broken controls.

Access-Control-Model

Example of Mixed Approach 2:

In the case of the following Mixed Approach the user is granted write:docs, read:logs, write:logs permissions then all restricted API points should be tested against these permissions as shown in the image below.

Access-Control-Model

Closing

In this case, the API point must have a pointer that can be a name, id, or Uid when referenced to another organization or a user from another organization points to IDOR. Therefore, all IDOR's are Access control issues. But all Access control issues are not IDOR's. .

my other article sources https://itsec.ac.id/

Bagikan
Cari Artikel
Top 5 Kategori
Artikel Terfavorit