Access control - simplifying testing with the authorize extension

Access Control Dilemma

Often in real-world application security testing, there is a challenge: how to define whether a vulnerability is an access control issue or not? Applications consist of various functionalities and views, and it is not always clear-cut what information should be visible to whom. A developer can easily argue that "this user should indeed see this information," making the assessment challenging.

Especially in applications with multiple roles and complex access control models, it can be difficult to grasp what users should or should not be allowed to do. In some cases, the boundaries are clearer, such as when the application has explicit user access restrictions, like personal functionalities. Sometimes, however, it is nearly impossible for an outsider to ensure who has access to what.

For this reason, it is always recommended to require a clear role description from the developer or client for each user role. This enables a systematic comparison between actual access control and application requirements, making it easier to identify vulnerabilities.

Why Use Tools Like Autorize?

Most often, the surest way to ensure that an application's access control is in order is to review its source code and verify that proper controls have been implemented correctly. However, this is not always possible if the source code is not available. So, what can be done in such a situation?

Manual checking for each functionality would be extremely time-consuming and inefficient. That is why various tools have been developed to expedite and enhance access control assessment, enabling a more comprehensive and systematic review. Let's see this in practice next.

Installing the Autorize Plugin

Let's start practicing using the Autorize plugin by installing it on BurpSuite tool. This can be easily done by navigating to the BApp store and searching for Autorize there.

Functionality of the Autorize Plugin

The functionality of the Autorize plugin is relatively straightforward. We have an application with various restrictions on who can see what. First, log in to the application using one user. If the application has multiple user levels, choose the lower user level from these two users being compared. Once logged in, copy the identified information of that user (for example, cookies) and set them in the Autorize settings.

Other possible additional settings can be configured, such as setting a filter based on which access control testing is to be targeted. For example, it can be specified that only requests containing a specific string should be tested. This can be useful, for instance, if you want to test only requests from a specific API area or similar.

When the settings are satisfactory (the only mandatory ones are those identification details), you can proceed by opening, for example, a new window in incognito mode. In this window, log in with the other user being compared, who in this example would have more privileges, i.e., the user at a higher level.

Once you have logged in with both accounts and Autorize is ready, activate the Autorize plugin.

Now when you make any request with the higher level user, the Autorize plugin simply repeats the same request by replacing the existing identification details (cookies of the higher-level user) with the identification details set in the Autorize plugin. Likewise, the plugin also attempts to repeat the same request without any identification details, i.e., completely unauthenticated. These requests and responses are then logged in the Autorize plugin's log.

Independent Practice

Next, practice using the Autorize plugin independently. In the application for the exercise below, there are three user levels: Admin, User, and unauthenticated user. The credentials for a normal user are user:user. Use these and first find a functionality in the application that lacks access control check. Then exploit this vulnerability to leak some information that does not belong to you from the application to earn a flag.