Toggle "User Order" vs "Request Order" mode for requests.

[verahayter]

Firstly, this extension is a lifesaver for testing complicated permissions systems with multiple roles / role combinations.

I've noticed that the extension loops over the requests and then loops over the users, so for instance, if there are Requests A, B, C and Users 1, 2, 3, it will perform Request A three times (one for each user) and then perform Request B three times, etc. What I propose is a way to change this so it performs Request A, then Request B, then Request C for User 1, then does the same thing for User 2, and finally User 3.

In cases where you want to test some modification of a resource, it may generate false positive results, if the resource is first modified by User 1, and subsequent modifications are just the result of the User 1 request rather than actual modification by other users.

[mickayz]

Thanks for the suggestion! I can see the value in letting the user pick this and will consider it for the next release.

In the meantime, the false positives can be used as a pretty good indicator of when there is a vuln in a resource-altering request.

When testing a request, lets say a DELETE request, your strategy can be to order the users from "least likely to succeed" to "most likely succeed". As of AuthMatrix 0.8, you can reorder users by dragging and dropping the column and it will modify what order they are run in.

So for example, if there is a DELETE request on an admin-only asset, you might order the users as such:

anon, user1, user2, admin1.

If there is a vuln and user1 succeeds in completing the DELETE request, it will most likely register admin1 as a false positive (with a blue checkbox) and you can review the exact requests made to find the first user that violated its authorization. Note that this strategy may get less reliable if multiple users should succeed in the DELETE.

The other way this strategy can be used is when you have the request that creates the resource as part of your configuration. Using a chain with the "Use Values From" field set, you can create a resource that belongs to just 1 individual user and use it in subsequent requests.

For instance lets say there are two requests: request#1 that creates a resource and returns an ID, and request#2 that takes an ID and deletes it. To test this you could do the following:

1. Pick one of your users to be the owner of that resource (lets say user2 from before)
2. Make the first request a "create resource" request. Ignore the roles for this request as its only there to setup the next request.
3. Make the second request a "delete resource" requests.
4. Create a chain that moves the resource ID from 1's response to 2's body. Set the "Use Value From" option to be user2.
5. Reorder the users so that user2 runs last.
6. Run the requests and check if there are any false positive results (blue).

In most cases, running this should identify any auth vulns in the "delete resource" request and can be repeated without needing to set anything up manually.

Hope that helps!