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.
Hey look we found an IDOR in this update notes function!
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 info@mccormackcyber.com
