top of page

There's a BApp for that: AuthMatrix

Previously I wrote a blog post on AutoRepeater (There's a BApp for that: AutoRepeater) which can be used to test Authorization among other things, the tool we are testing today can be helpful when there are a multitude of user roles you would like to test against.

This BApp provides a simple way to test authorization in web applications and web services. With AuthMatrix, testers focus on thoroughly defining tables of users, roles, and requests for their specific target application upfront. These tables are structured in a similar format to that of an access control matrix common in various threat modeling methodologies.

Once the tables have been assembled, testers can use the simple click-to-run interface to kick off all combinations of roles and requests. The results can be confirmed with an easy to read, color-coded interface indicating any authorization vulnerabilities detected in the system.

Zachary Stashis


(1) Installation

Extender > BApp Store > AuthMatrix > Select "Install"

(2) Usage

Open AutMatrix Tab, and create a new user by selecting "New User"

Create a User Account for each type of permission you are testing for, select "OK"

For this example, we created the following:

Next, specify permissions for the different types of roles you are creating, by selecting "New Role"

Create the new role, select "OK"

For this example, we created the following Roles:

Now define which access each user level has by selecting the appropriate check boxes:

Now log in with each user level you want to test with, take their cookie values, and then enter them into the cookie column (by double clicking the empty cookie value - the unauthenticated user will have no cookie value):

After you set each user's cookie, crawl the site as you normally would and send requests to AuthMatrix, then highlight the request in the AuthMatrix tab and select "run". (It is suggested to start with the highest authenticated user first to see what lower accounts might have access to pages they might not be able to see, such as the administrative pages. Then working your way down through each user account and doing the same. If Customer 1 shouldn't see Customer 2's page, then that is a vulnerability.)

After you've replayed all the requests you will see something like this (displaying which users had access to what):

It's straight forward to understand, you can drill down further by selecting a request and see the different tabs of response/request and what each user was able to successfully access.

(3) Advanced Usage (Chains):


Chains provide a way to copy a static or dynamic value into the body of a request. These values can be pulled from the response of a previously run request (using a regex) or by specifying user-specific static string values.

The most common use cases for Chains are:

1. Populating requests with valid CSRF Tokens

2. Testing newly created IDs/GUIDs for cross-user authorization issues

3. Automating authentication and session refreshing

A Chain entry has the following values:

  • Chain Name: a descriptive name

  • Source: a static user string defined in the User Table or the ID of the source request in the Request table

  • Extraction Regex: a regex used to extract a value from the response of the source request. This field is only used when a Request is specified in the previous field. If used, this must contain one parenthesis grouping that is to be extracted [i.e. (.*)]

  • Destinations: a list of Request IDs that the source value will be replaced into.

  • Replacement Regex: a regex used to determine where the source value is to be inserted. This must contain one parenthesis grouping to be replaced [i.e. (.*)]

  • Use Values From: specify whether to use the source value obtained from one selected user (useful for cross-user resource tests) or to use the values from all users and place them into their corresponding user's destination requests (useful for automation tasks like CSRF token retrieval)

NOTE: Requests are run in order of row, however, if a chain dependency is detected, AuthMatrix will run the requests in the required order.

(4) Creating a Chain

Select "New Chain" from the bottom menu:

Then the new menu will appear:

(5) Chains for CSRF

*note: to enable the chain right click on it and select enable, the screen shot below is from a previous version that had radio buttons.

(6) Chains for Cross-User Resource Tests

*Note: to enable the chain right click on it and select enable, the screen shot below is from a previous version that had radio buttons.

(7) Chains for Authenticating Users

*Note: to enable the chain right click on it and select enable, the screen shot below is from a previous version that had radio buttons.

(8) Failure Regex Mode

For certain targets, it may be easier to configure AuthMatrix to detect the response condition of when a request has failed. For example, if a target site returns unique data on successful requests, but always returns an HTTP 303 when an unauthorized action is performed.

In this mode, AuthMatrix will validate this regex for all users not part of a succeeding role.

To do this, right click the request and select "Toggle Regex Mode". The regex field will be highlighted in purple to indicate that AuthMatrix will run the request in Failure Regex Mode.

NOTE: False positive detection and highlighting may not work in Failure Regex Mode

Sample Configuration with Failure Regex Mode

(9) Sample Configuration with Failure Regex Mode

(10) JSON State File

81 views0 comments
bottom of page