How to test the Authorization Matrix?

by Excellium SA

Share

How to test the Authorization Matrix?

by Excellium SA

by Excellium SA

What is an authorization matrix? How to implement it? If those are some questions you need to answer, you’re at the right place. In today’s article, we cover how to test the Authorization Matrix.

Even if you are using an up-to-date framework with all security guidelines respected, there is a type of vulnerability that is not directly related to the code, but to the management of authorizations for the different functionalities of the application.

For basic web applications where only two roles are defined like “Administrator” and “User”, the authorization control is often based on the URL. For instance, to access the /admin zone, the application will check if the user has the administrator role or not.

However, in more complex applications that need to manage three, four or more roles with different levels of access for each feature, the authorizations could be way more complex to implement and to check.

2 screens with codes

Defining an authorization matrix

A first step before going deep into coding is to define the authorization matrix like the Matrix M1. That matrix will contain on one side the different roles of the application-defined during the definition of the business requirements. On the other side, it will contain the functionalities of the application. Most of the time, these functionalities are related to an API endpoint and the four actions of the CRUD (Create, Read, Update, Delete) model. Doing a test with that kind of  authorization matrix will allow the tester to check if a vertical privilege escalation is available, i.e.: if a basic user can access admin data.

Matrix M1

Action/Role Anonymous Authenticated user Validator Administrator IT admin
Access to Homepage Y Y Y Y Y
Create a Bill N Y N N N
Update a Bill N Y (Only his own, see M2) Y Y N
Validate a Bill N N Y N N
Second Validation of the Bill N N Y (With 4eyes check, see M3) N N
Manager user N N N Y N
View application error logs N N N N Y

In addition, another authorization matrix can be defined with more details for each role in order to define if a user of a given role can view/update/delete data of another user with the same role as shown on the Matrix M2 and M3. Therefore, even if there is no privilege escalation (like a basic user accessing the admin panel) when a basic user can alter the data of another basic user, it raises a security issue. That kind of privilege escalation is named horizontal due to the fact that both users have the same level of right but not the same view on the data.

Matrix M2

Action/Role Authenticated user U1 Authenticated user U2
View bill created by user U1 Y Y
Update bill created by user U1 Y N
Delete bill created by user U1 N N

Matrix M3

Action/Role Validator V1 Validator V2 Administrator
First validation of the bill B Y Y N
Second validation of bill B N (A is the first validator, 4eyes check) Y (B is not the first validator, 4eyes check) N
Delete bill B Y N Y

Implementation of the Authorization matrix

The most important point is to implement the authorization matrix on the server-side. Sometimes, the application only checks the authorization on the client-side based on a string stored in a cookie for example. The JavaScript code checks if the “role” string contains “user” or “moderator”, and then displays or not some action buttons.

However, even if the button is not displayed on the WUI, it could be possible to call the corresponding endpoint as we are doing during an intrusion test. That point will be explained in the next part.

Therefore, the server side must check the user role for all entry points of the application. In order to avoid missing checks on some endpoints, the application should check if the user is logged for all requests, and then some exceptions could be added on some endpoints like the home page, the login form, the forgot password page. This is especially true for websites without public pages except the ones listed before.

Then, if the application is composed of a Controller for each type of role, it will be easier to control the entry points inside it. For example, on the Controller managing the Admin functionalities, a global check should be made in order to ensure that the user is an administrator. The same should be made for the Bill management and the Validator role. That approach will avoid some missing validations on endpoints within the controller.  Finally, only some exceptions could be added one some endpoint if the business needs it, like for a four-eyes check.

For the four-eyes check, the control should be done on the validation method itself. For the first validation, any Validator user can call that endpoint, however, if the first validation was made and if the same Validator tries to call it, an error should be raised.

With these recommendations, the base of the authorization check is fulfilled. The authorization matrix check can be done easily, and in the case of code reviews, the matrix could be given in order to ensure that the implementation respects all the authorization.

Dynamic tests

In the OWASP web testing guide, the test of the authorizations matrix comes in fourth place. That point is one of the most important for the business. If a simple user can access administrator functionalities, the result could lead to a disaster for the company.

During intrusion tests, most of the time, testers use a proxy in order to alter and replay some requests. The best-known tools are Burp (Freemium) and ZapProxy (Free/OpenSource). However, these tests could also be made with a simple curl command.

The first thing to do is to browse all the functionalities with different roles and create a sitemap. When the sitemap is complete, the consultant will try to access some of them with a user who should not have the right. To do that, the consultant takes a request made by an admin for example and just replaces the cookie (or the authentication item) with the one of a standard user. The application should respond to a 403 Forbidden (or another error message). If the request does not fail, either the authorization matrix is incorrect, or it is indeed a security issue.

The developer/testing team can create a few curl commands on a script like unit tests. A request should be made for each endpoint and for each iteration. The authentication item used will be the one of a user, a validator, an admin, etc. That allows the tester to perform the test before going live or between each step of the development life cycle. Note that manual testing authorization is very error-prone, therefore, it is highly recommended to automate this kind of test using a test plan. Tools like Venom (Free/OpenSource) can be used to create test plans using a descriptive approach.

For an intrusion test, the usage of tools like Burp/Zap will be better and that could be eased with plugins like the Burp AuthMatrix plugin. The consultant recreates the matrix and by providing a cookie for each user, the plugin will perform all requests that the consultant described on that matrix.

The authorization matrix: mandatory or not?

The authorization matrix is mandatory documentation for the application. That will help the developer implement the business requirements without ambiguity. The testing team can also create some scripts and use cases to apply between each release. The authorization matrix’s document could be given for an intrusion test or a code review to the consultant to validate what kinds of actions are allowed or not, especially if the application contains multiple roles and specific use cases like four-eyes check.

Did you enjoy the reading? Find more articles on our blog!

Credits

Valentin GIANNINI

References

Top