The Burp extension helps you to find authorization bugs. Just navigate through the web application with a high privileged user and let the Auth Analyzer repeat your requests for any defined non-privileged user. With the possibility to define Parameters the Auth Analyzer is able to extract and replace parameter values automatically. With this for instance, CSRF tokens or even whole session characteristics can be auto extracted from responses and replaced in further requests. Each response will be analyzed and tagged on its bypass status.
There are other existing Burp Extensions doing basically similar stuff. However, the force of the parameter feature and automatic value extraction is the main reason for choosing Auth Analyzer. With this you don’t have to know the content of the data which must be exchanged. You can easily define your parameters and cookies and Auth Analyzer will catch on the fly the values needed. The Auth Analyzer does not perform any preflight requests. It does basically just the same thing as your web app. With your defined user roles / sessions.
(1) Create or Clone a Session for every user you want to test.
(2) Save and load session setup
(3) Specify the session characteristics (Header(s) and / or Parameter(s) to replace)
(4) Set Filters if needed
(5) Start / Stop and Pause Auth Analyzer
(6) Specify table filter
(7) Navigate through Web App with another user and track results of the repeated requests
(8) Export table data to XML or HTML
(9) Manually analyze original and repeated requests / responses
If you have the resources you want to test in your sitemap, it is very easy and quick to perform your authorization tests. In the very first step define your sessions you want to test. Then just expand your sitemap, select the resources and repeat the requests through the context menu. Additionally you can define some options which requests should be repeated and which not. With this you can perform authorization tests of a complex website within seconds.
The Auth Analyzer has the possibility to define parameters which are replaced before the request for the given session will be repeated. The value for the given parameter can be set according to different requirements.
The parameter value will be extracted if it occurs in a response with one of the following constraints:
A response with a Set-Cookie Header
with a Cookie name set to the defined Extract Field Name
An HTML Document Response
contains an input field with the name attribute set to the defined Extract Field Name
A JSON Response
contains a key set to the Extract Field Name
Per default the Auth Analyzer tries to auto extract the parameter value from all locations. However, clicking on the parameter settings icon lets you restrict the auto extract location according to your needs.
The parameter will be extracted if the response contains the specified From String
and To String
in a line. The From-To String can be set either manually or directly by the corresponding context menu. Just mark the word you want to extract in any response and set as From-To Extract
for the parameter you like.
Per default the Auth Analyzer tries to extract the value from header and body at most textual responses. However, clicking on the parameter settings icon lets you restrict the From-To extract location according to your needs.
A static parameter value can be defined. This can be used for instance for static CSRF tokens or login credentials.
You will be prompted for input if the defined parameter is present in a request. This can be used for instance to set 2FA codes.
If a value is set (extracted or defined by the user) it will be replaced if the corresponding parameter is present in a request. The conditions for parameter replacements are:
The parameter will be replaced if it is present at one of the following locations:
In Path
(e.g. /api/user/99/profile
--> if a parameter named user
is present, the value 99
will be replaced)
URL Parameter
(e.g. email=hans.wurst[a]gmail.com
)
Cookie Parameter
(e.g. PHPSESSID=mb8rkrcdg8765dt91vpum4u21v
)
Body Parameter
either URL-Encoded
or Multipart Form Data
JSON Parameter
(e.g. {"email":"hans.wurst[a]gmail.com"}
)
Per default the parameter value will be replaced at each location. However, clicking on the parameter settings icon lets you restrict the location according to your needs.
The defined parameter can be removed completely for instance to test CSRF check mechanisms.
Define the username and password as a static value
. The session cookie name must be defined as auto extract
. Verify that you start navigating through the application with no session cookie set. Login to the web app. The Auth Analyzer will repeat the login request with the static parameters and automatically gets the session by the Set-Cookie
header. This Cookie will be used for further requests of the given session. The defined Cookie will be treated as a parameter and therefore no Cookie Header must be defined.
Hint: You can restrict the extract and replace conditions for a parameter to avoid malfunction at the extracting / replacing stage.
Define a Cookie header and a CSRF token (with auto value extract
). The CSRF token value will be extracted if it is present in an HTML Input Tag
, a Set-Cookie Header
or a JSON Response
of the given session.
Since the Auto Extract
method only works on HTML Input Fields
, JSON Objects
or Set-Cookie Headers
we must use the generic extraction method called From To String
. With this extraction method we can extract any value from a response if it is located between a unique starting and ending string. The Auth Analyzer provides a context menu method to set the From String
and To String
automatically. Just mark the String you want to extract and set as From-To Extract
by the context menu.
Since the Authorization Header is not treated as a parameter (as it is done with the Cookie Header), we can use a header insertion point to achieve what we want. Just mark and right click the value you want to replace in the specified header. The defaultvalue
will be used if no parameter value is extracted yet.
Just create as many sessions as you want to test several roles at a time.
Just press Renew
on the session status panel or repeat the affected request by the context menu (mouse right click in the table entry). Hint: The login request(s) can be marked and filtered afterwards.
Original Requests can be dropped for testing idempotent operations (e.g. a DELETE
function).
If an anonymous user needs a valid characteristic (e.g., a valid cookie value) you have to define the header as usual. Otherwise, you can define a header to remove as follows:
You can easily test a large number of endpoints on its individual CORS settings by adding an Origin header at Header(s) to replace
and select Test CORS
on the Session Panel. By selecting Test CORS
the Auth Analyzer will change the HTTP method to OPTIONS
before the request is repeated
A specified parameter can be removed by selecting the Remove Checkbox
. This can be used for instance to test the CSRF check mechanism.
The Auth Analyzer provides a build in comparison view to verify the differences between two responses. Just mark the message you want to analyze and change the message view (1)
. You are now able to compare the two requests (2) (3)
. The built in Diff
Feature will calculate and show the differences between the two requests in real time (4)
Expanded Diff view:
The Auth Analyzer should process two types of requests / responses:
The response contains a value which must be extracted
The requested resource should not be accessible by the defined session(s)
For instance, we don’t want to process a static JavaScript file because it is accessible for everyone and (hopefully) does not contain any protected data. To achieve this, we can set following types of filters:
Both Responses have same Response Body
and same Response Code
Both Responses have same Response Code
and Both Responses have +-5% of response body length