Simplifying Authorization Testing in Burp Part 2
Automation is our friend
Naturally, we will utilize tools and manual techniques to assess any given application. However, leveraging automation to perform simple, and mundane, tasks is incredibly beneficial. This has never been more true than when looking at authorization testing as the task becomes more burdensome the larger an application is, or the more user roles it has.
As noted in our first post on this subject there are some great tools available to help us automate these tasks. While there are a multitude of options including tools such as Autorize, AutoRepeater, and AuthMatrix, I prefer to use Auth Analyzer. If you want a quick guide on capturing multiple sessions to begin with check out part 1 here.
Setting up our authorization automation
Let's go over some of the configuration options we will be interested in when working with Auth Analyzer. Below is an example of the auth analyzer tab in Burp:
You can create as many sessions as needed, and I would recommend creating a session for each user role you need to test. This will allow auth analyzer to replay requests for you with each test case all at once as you navigate through the application from your main session. To keep things simple, I like to name mine based on my color schemes that those sessions will be utilizing in our Burp history tab, and I also always like to include an unauthenticated session just to check for unauthorized access to resources quickly.
Once you are ready to configure a session there are multiple options in the center. For our unauthenticated example this is almost always what you need to do and that is simply tell Auth Analyzer to remove the Cookie header, or the Authentication header. In our example we are removing the Cookie header which would remove the sessions cookies to our target site.
The important part to remember when configuring your sessions is that the first section "Header(s) to Replace" is what you want that particular header to be once it IS replaced. The lower section to add parameters can be used to automatically extract things such as dynamic CSRF tokens and add them as needed. For most simple applications just adding the headers to replace is all that is required.
Now all there is to do is to start the session and begin interacting with the application. For my example I have two user roles so I capture one as "dark blue" and one as "light blue" I decided to work from my dark blue tab so I placed the appropriate authentication headers into the "Headers to Replace" of the light blue tab's session. In the screenshot below you can see that we can review the requests and responses of our original requests as well as every session we have running.
Some other helpful tips when using this tool include taking advantage of the "Drop Original Requests" in the top right just below our on/off button. This will make it so your original request isn't forwarded through the Burp proxy which is helpful when testing functions such as an edit or delete where you need to ensure that the other session actually made the change.
The table will also populate with the status of each request and provide notes such as "Different" and "Same" which are loosely intended to help quickly spot potential problem areas. Do remember to always triage these suggestions to rule out false positives as the tool will replay every request that goes through the proxy. This could include shared resources, which will be flagged as being the same in the table. Additionally, as seen in our example above it lists "Not Applicable" in the table because we dropped the original request.
While our example is a fairly simple setup we will cover handling dynamic tokens such as CSRF tokens that change with each request in a future part 3. For now this should provide a fast and easy way to review authorization in a majority of applications and APIs that you interact with on a regular basis.
Are you looking for a security assessment for your network or applications? Send us an email at firstname.lastname@example.org