Broken Access Control

In 2021, vulnerabilities in authorization scheme were ranked as the top risk in web applications by the OWASP Top 10 project for the first time in its existence. As we will see, finding authorization errors requires a meticulous and structured approach. For example, to test access controls, we need a basic understanding of an application's functionality. Therefore, we should address the following questions:

• Which user roles have been implemented?
• What permissions have been assigned to each user role and how do they differ from each other?
• Is the target system multi-client capable?

From these questions, we can derive two essential pentest tasks: checking horizontal and vertical user authorization. While horizontal privilege escalation aims to access third-party data, vertical privilege escalation attempts to leverage the privileges of other user roles. Such vulnerabilities could be identified by manipulating IDs in HTTP endpoints. However, without knowledge of an application's dataset, we are in the dark when it comes to analysis. At the same time, we should remember that we have limited time to perform a pentest. To increase the cost-benefit factor, we should request at least two user accounts per role from the client. With these credentials, we can navigate through an application from different perspectives, intercept all HTTP requests with a proxy, and then exchange session IDs or access tokens with those of other user accounts. As can be seen from the following graphic, we would need at least 8 test accounts, for example, if three user roles have been implemented and the application is also multi-tenant:

Let's assume, for example, that we want to check in a customer relationship management system (CRM) whether a project manager can assign himself the admin role via the user administration that is hidden from him. To do this, we would have to initialize a session with the test accounts 'pentest-project-manager-01' and 'pentest-admin-01' and save their session cookies:

pentest-project-manager-01

Set-Cookie: JSESSIONID=E887430CAB542256EF52E56FF6204295; Path=/; HttpOnly

pentest-admin-01

Set-Cookie: JSESSIONID=50B6753AB49518F9121C05CF6C64280B; Path=/; HttpOnly

Then, as user 'pentest-admin-01', we would change the user role from 'pentest-project-manager-01' via the CRM's user interface and replace the session cookie in the intercepted HTTP request in Burp Suite with the session cookie of 'pentest-projectmanager-01':

POST /user/31  HTTP/1.1
Host: crm.dubius-payment.com
Cookie: JSESSIONID=E887430CAB542256EF52E56FF6204295
Content-Type: application/json
Content-Length: 51
Connection: close

{
    "data":{
        "admin_flag":1
    }
}

We would have to go through this procedure for all possible combinations within an authorization structure to avoid overlooking an authorization error. In doing so, we must not be fazed by our own logic errors. One possible pitfall in checking authorization management is deletion operations. Of course, we can only delete data if it exists in the application. However, if we are careless, we could execute the HTTP request method 'DELETE' on a resource that we have already deleted, which would falsify the result of our authorization test.

In addition to horizontal and vertical privilege escalation, we must also verify that user authentication cannot be bypassed via direct page requests. In detail, this means that we must submit all intercepted HTTP requests from the various user roles without any identifiers such as session IDs or access tokens.