Automating Authorization Testing: AuthMatrix – Part 1

If you’ve ever encountered a large web application with multiple roles, each with their own distinct permissions, you will understand the pain that comes with testing for authorization issues. Perhaps you do everything manually, swapping out cookies for each request, or maybe you use the Burp extension, Autorize, to help automate some of the process. I’m here today to tell you that you’re doing it wrong and that you should be using AuthMatrix instead.

What Is Authorization Testing?

Firstly, let’s briefly cover what “authorization testing” is. If an application has an admin role, then that admin role will likely be able to access some special admin functionality. If, however, a regular user role can also access that functionality, by simply visiting the same URL, then you have an authorization issue. The user role is not “authorized” to access the admin functionality, but can anyway, because the application doesn’t perform the necessary checks. This example is generally known as privilege escalation.

However, there is another type of authorization issue: Insecure Direct Object Reference (IDOR). This occurs when users of the same role can access resources that belong to the other user. For example, if users can update each other’s emails in an application by changing a userId field in a URL, that would be an authorization issue as well. Both these types need to be tested, which is where AuthMatrix comes in.

AuthMatrix is, quite literally, my favorite Burp extension. It gained that respect from the sheer number of hours I know it’s saved me, combined with the number of authorization issues it has found. I think most people who avoid AuthMatrix do so because the learning curve can be steep, however in this series of blogs, we will teach you how to use AuthMatrix for various scenarios. In this post, we will cover basic setup of roles, users, and requests for a simple application that only uses cookies.

Installing AuthMatrix & Getting Started

AuthMatrix can be installed from the BApp store in Burp Suite, and when first loaded, it looks like the image below. The top section is where we will define our users, the section below that will be where we send the requests we wish to test, and the other sections we won’t worry about for now.

First let’s set up the roles. In this demo application, there are three roles: Admin, Manager, and User. However, there is another role that is implicit: the unauthenticated user. We have 5 pages in our application:

• Index
• Dashboard
• Items page
• Management page
• Admin page

The breakdown of intended access to these pages per role is as follows:

The only page everyone should access is the index page, which is required so that users can log in there. Other than that, the access rules should make sense.

Setting Up Roles In AuthMatrix

Setting this up in AuthMatrix is relatively simple. First we’ll set up the roles by clicking the “New Role” button at the bottom of the screen. For reasons that will become clear, instead of an “Unauthenticated” role, we’re going to create an “Authenticated” role and assign it to all our users except the Unauthenticated one.

Once we have our roles in place, we can add users using the “New User” button. Next, we’ll assign our users to roles by checking the relevant boxes. For example, in the Admin user row, we’ll need to check the “Admin” role box, and the “Authenticated” role box. The “Unauthenticated” user should have no boxes checked. 

The users section will now look like this:

Once we have our users setup, we will login to the application using the highest privilege user (Admin) and browse to the 5 pages in turn. After we’ve done this, we’ll select all 5 requests in Burp’s proxy tab, right-click, choose “Extensions”, then “AuthMatrix”, and finally “Send request(s) to AuthMatrix”. 

The requests section of AuthMatrix should now look like this (I have deleted some unnecessary columns):

We can leave the Response Regex alone for now, but we’ll cover it in another blog post. For now, we need to use the checkboxes next to each request to tell AuthMatrix which roles / users can access which pages. This is why we have an “Authenticated” role, so that instead of checking the first three rows for Admin, Manager, and User, we just have to check them for the “Authenticated”. 

The completed section looks like this:

The only thing we need to do now is provide AuthMatrix with the correct cookie values for each user. We can do this by logging in as each user in a new private browsing session, and sending the cookie to AuthMatrix by right-clicking on a request containing the cookie, selecting “Extensions”, then “AuthMatrix”, and finally “Send cookies to AuthMatrix user: <user>” where <user> is the user the cookies belong to.

Note that unless the application sets a session cookie for an unauthenticated user, you will have to manually add one in the “Cookies” field for the Unauthenticated user in AuthMatrix by double clicking on the field. You can leave the value blank (e.g. sessionId= ) as long as it exists in the field.

With everything set up, click the “Run” button and watch as AuthMatrix sends each request multiple times, swapping out the cookies for each user and determining whether or not an access control violation occurred (by checking the Response Regex – a 401 status code is used for when an unauthorized user attempts to access a page). It then colors the request / role matrix cells green if no violation occurred, and red if one did:

Based on the red cells in the above screenshot, we know that despite the intended access rights, the Manager role can apparently access the /admin page, the User role can access the /management page, and the Unauthenticated user can access the /items page. The red cells in the Authenticated column appear because the Manager and User roles are authenticated and have access violations.

You can save your AuthMatrix setup as well, meaning that when it comes time to retest the findings, you can simply load it, set the cookies again, and click “Run” to see if the customer implemented proper authorization checks.

Next Up

In the next blog post in this series, we will look at more complicated setups that some applications may require.

Part 2 is available!!

MORE FROM WHITE OAK SECURITY

White Oak Security is a highly skilled and knowledgeable cyber security testing company that works hard to get into the minds of opponents to help protect those we serve from malicious threats through expertise, integrity, and passion. 

Read more from White Oak Security’s pentesting team.