Tiredful API is an intentionally vulnerable REST API. I am going to use it to practice a bunch of Burp tricks.
In this part, I want to show how to use Burp macros to detect invalid session and add a custom bearer token header to the requests.
I used the instructions to spin up a docker container and used it with the free Burp Community Edition 1.7.36.
Often times the session times out in the middle of testing or scanning. I only use Burp's scanner on individual requests but session can still time out. Sometimes the application log users out after sending funny payloads. Burp allows you to detect invalidated sessions and run a macro (which is a series of requests) to update the session automagically.
Usually, the session is maintained by cookies and Burp's cookie jar can be automatically updated to refresh the session. In the case of this API, we are using a Bearer token. But this method can be used for any custom header containing a token.
The login request is simple. While this example has only one request, the process for multiple-step requests is similar. The application has two registered users. We are using batman:Batman@123
.
Successful login request
The access_token
must be added to every authenticated request like Authorization : Bearer [token]
.
We also need to detect invalidate sessions. To do so, navigate to http://192.168.99.100:8000/api/v1/advertisements/ to see the response.
Invalid request
We are going to use the header 401 Unauthorized
to detect invalid requests.
We should create a login macro to login as batman
. This macro will be executed when Burp detects an invalid/expired session.
Project Options > Sessions
and scroll down to Macros
.Add
to create a new macro. Macros are created from existing requests.Ok
.
Selecting the login request in macro recorderOk
in Macro Editor
to create the macro. If the request had specific parameters (e.g. a CSRF token), we could designate it in Configure item
. This example does not need it.
Finish macro recordingWe need to make Burp perform two action:
access_token
as a custom header to that request and resend it.In order to accomplish number two, we need to use an extension. Burp vanilla does not support adding headers to requests in session validation rules. However, cookies and normal GET/POST parameters (e.g. form-urlencoded
) can be updated.
Add Custom Header
extension at https://github.com/lorenzog/burpAddCustomHeader. It's also available in the Burp App Store.Add Custom Header
tab. It's pre-populated with some sane defaults.access_token":"(.*?)"
. The underline does not show up in the input field but you can click on Update Preview
to see it.access_token":
. Our regex will be access_token": "(.*?)"
instead.
Add Custom Header setupProject Options > Sessions
) click Add
under Session Handling Rules
.session-validation
.Rule Actions
click Add
and select Check session is valid
.
Session validation rule - 1Issue current request
under Make request(s) to validate session
. This tells Burp to modify the same request with the new header and resend it.Inspect response to determine session validity
, select HTTP headers
and enter 401 Unauthorized
in the Look for expression
field. This section determines how Burp detects invalid sessions. We are telling Burp that the session is invalid if 401 Unauthorized
appears in the response header.Match indicates
must be set to invalid session
. We are telling Burp how to detect invalid sessions after all.
Session validation rule - 2Define behavior dependent on session validity
check If session is invalid, perform the action below
, check Run a macro
and select the login macro.Update current request
boxes (doesn't matter in this example, we are not using cookies or parameters).After running the macro, invoke a Burp extension action handler:
and select Add Custom Header
. Response of the last request in the macro is passed to Add Custom Header
. The extension extract sthe token using the regex (remember the match group) and adds it as a header to the request.
Session validation rule - 3Ok
and we're back at the first screen. Now we need to select the scope.scope
tab and select any tool that needs this rule under Tools Scope
. We will go with the default.URL Scope
select Use suite scope
. We will set it later.
Setting scopeInstead of detecting the session, we can use an easier rule and run the macro and add the header to every request. I went with the more complicated process because I wanted to practice setting it up.
Rule Actions
which is Add (button) > Run a Macro
.After running the macro
and select Add Custom Header
.
Alternate ruleIn this example, we do not have to set the scope. But usually, we want to only operate in a specific scope. In my VM, the address is http://192.168.99.100:8000
so I added it in Target > Scope
tab. I also excluded the login and logout API endpoints.
Scope
Now it's time to see the fruit of our labor. Right click the request to http://192.168.99.100:8000/api/v1/advertisements/
in Burp history and send it to Repeater. Click Send
and see the header added to the request and get a valid response. It's empty but it's valid.
Burp in Action
Tune in for the next section, where I talk about using Burp's sitemap comparison.