In my previous blog post, part 1, I covered the basic configuration of the AuthMatrix Burp Suite extension, so we will now move on to some more advanced setups.
The concept which seems to cause the most confusion in AuthMatrix is that of chains, which is a shame because chains are an incredibly powerful tool. At a basic level, a chain can be thought of as a search / replace, allowing you to modify a request in AuthMatrix before it gets sent.
As explained in part 1, requests in AuthMatrix are automatically updated with the provided cookie values for each user, and headers can also be set using the “New Header” button. What if a certain parameter in a request is user-specific and needs to be updated? This is where chains can be used.
A common example of where this might be useful is with anti-CSRF tokens. Consider an application that uses an anti-CSRF token for each user that remains the same throughout the duration of their session (this is typical behavior). This token is part of all forms within the application HTML code, so it gets sent automatically with every POST request. If one of these POST requests is sent to AuthMatrix, it will fail when AuthMatrix sends it with the session cookies of another user, since the anti-CSRF token does not belong to that session.
There are two ways we could fix this in AuthMatrix. This blog post will cover one way, and my next blog post will cover the other. The first way is very similar to how we handle cookies. First, we click “New Chain Source” and add a relevant label (e.g. “Anti-CSRF Token”).
Once the OK button is pressed, you should notice a new column in the user’s section with the same name. We can double-click in each user row’s corresponding cell and set the value of that user’s current Anti-CSRF Token.
Now we need to create a chain that searches for a certain pattern in the original request and replaces part of that match with the user’s Anti-CSRF Token. In our imagined application, requests send the Anti-CSRF Token using the parameter “token”, like so:
id=5&action=save&token=ce99b1b8b4bc2ef59469e054b86362f6We can use our knowledge of the token’s format to create a narrow search, so as not to match more than just the token itself. Since in this instance, the token is comprised of 32 hexadecimal characters, the following regular expression (regex) should match:
token=([0-9a-f]{32})The use of parenthesis () around the token regex itself is important, as AuthMatrix uses it to determine what to replace in the request. We don’t want to replace the token= part of the request, just the actual token that comes after it.
Now we have our regex, we can add a chain to do the replacement. Click the “New Chain” button, and a new chain should be added in the section below the list of requests.
Modify the Chain Name by double clicking and providing a more descriptive name. In the Source column, click and select our Chain Source (“Anti-CSRF Token”) from the drop-down. In the Destination(s) column, click to select the requests that you want the chain to update. Finally, in the “Regex – Replace into HTTP Request” column, double-click and paste our regular expression. Your chain should look similar to this:
Save your AuthMatrix configuration, and click “Run”. Once AuthMatrix completes, you can check the requests to make sure that the token actually got replaced. Here is a side-by-side comparison of the original request and the request AuthMatrix sent as the Admin user, using the token taken from the Chain Source.
In my next blog post in this series, we will look at more advanced usage of chains, as we automate more of our authorization testing process.
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.