The Importance of Automated Session Management in BurpSuite

Efficient cybersecurity testing almost always requires automated session management in the testing tool.

Automating allows, for example, the ability to leave the scanner scanning the application's various functions overnight, and Burp knows how to automatically log the test user back in when the session expires.

With automation, you can also at any time take a request from the sitemap, put it in the repeater and send it to the application, letting Burp take care of cookies, tokens or whatever session management method is - update.

Components of automated session management

In order to be realized, automated session management requires the following components:

: The mechanism for keeping track of the current session.

: Mechanism for updating the cookies/headers/other (depends on the application) of an HTTP request with the current session information.

: Mechanism to detect that the current session has expired.

: Mechanism for logging in when necessary.

The capability of Burp Suite for automated session handling - Session Handling Rules

Burp Suite has built-in capability to create session handling rules that implement all four aforementioned requirements.

The session management rules can be found in the Burp settings and by default, there is one rule already prepared in the project:

It is called "Use cookies from Burp's cookie jar".

It is restricted to the Scanner tool only.

Contains only one rule, which is "Use cookies from Burp's cookie jar".

How are Burp Suite session management rules built?

Burp session management rules are built upon description, scope, and a series of steps that are executed in order from start to finish, unless the execution is interrupted.

The session management policy has a description that can be defined by oneself.

Tools scope once again defines to which Burp tools the session handling rules are applied. If you want, for example, the Repeater tool to stay automatically logged in the way you want, set it in the Repeater scope. If it's not in the scope, session handling won't affect Repeater and cookies, etc., won't be updated automatically.

A proxy tool is rarely included in scope, but it also has valid use cases. One typical use case is running a third-party testing tool (such as sqlmap) through Burp, with the idea that Burp will ensure that the session remains valid throughout the entire scan.

URL scope determines to which URL addresses the session management policy is applied. Typically, one of the following is used:

: Use this when you have set only those URLs in Burp suite scope to which outgoing requests you want to be processed with this session management rule, and the scope does not have multiple targets, for example.

: Use this when there are multiple targets in the Burp scope and you want the Burp session handling automation to behave differently depending on the target.

There is also an option "Include all URLs", but its use is not recommended due to high risk of damage (sending authentication credentials of the target application to a completely wrong application by mistake).

The rule consists of individual rules that are executed for each HTTP request within the scope one at a time from top to bottom, until completion or interruption of the execution.

: Updates all HTTP request cookies from Burp's cookie storage.

: Set a specific URL parameter, body parameter, or cookie.

: Checks if the current session is valid.

Option 1: Infer from the current HTTP request and response.

Option 2: Run a recorded HTTP request or sequence (Macro) with current session data and infer from it.

: Prompt the user manually to notify if the session expires so that you can manually log in again.

: Run a Macro (which actually is a stack recorded with one or more HTTP requests).

: Launch a Burp extension that implements the ISessionHandlingAction interface.

: Set the value of a specific HTTP header.

How do Burp session management rules work?

A typical rule set could work as follows.

You send an HTTP request with a repeater to the address https://www.example.com.

Burp checks for enabled session management rules

Burp checks if there is a rule in the enabled session handling rules that has Tool scope as Repeater.

Burp checks these rules to see if any of them have a URL scope that is "https://www.example.com".

If such a rule is found, Burp will start executing its rules. Let's imagine that the rules are as follows:

Use cookies from the session handling cookie jar

Retrieve the Location header from the current HTTP response for the HTTP request at hand

Burp updates the cookies of the HTTP request from Burp's cookie jar.

Burp sends a modified HTTP request to the web server.

Burp checks the HTTP response and determines if the session is still valid.

The HTTP response contains a "Location" header that redirects to the login page, which means that the session is not valid.

Execute a recorded Macro that sends a POST request to the login page with the username and password.

Take the cookies received from the response and save them in Burp's cookie jar.

Burp Cookie Jar - How cookies are updated to the jar and where to find the jar?

The Burp cookie jar can be used and updated from the session management rules.

The cookie jar can also be set to automatically update from certain tools seen in Burp's HTTP responses, and the jar can be manually modified and inspected. This is done through Burp's "Sessions" section in the settings.

Session management rules can become complex and sometimes it can be difficult to say why a rule does not work as desired. For this reason, Burp includes a tool called "Session Tracer" (found in the same "Sessions" section of the settings) which allows you to track the execution of session management rules rule by rule.

Next, we will use a real application as an example and build a functional session management policy! If you want, you can launch the task page at the bottom of this stage and do it yourself.

First, you need to figure out how the application identifies the user and manages sessions. After completing the research phase, you will know all four necessary components (session database, update mechanism, detection mechanism, and authentication mechanism).

Let's start by opening Burp's browser and setting the scope appropriately.

Let's then log in and examine HTTP traffic with Burp.

## 

---

## The Importance of Automated Session Management in BurpSuite

Efficient cybersecurity testing almost always requires automated session management in the testing tool.

Automating allows, for example, the ability to leave the scanner scanning the application's various functions overnight, and Burp knows how to automatically log the test user back in when the session expires.

With automation, you can also at any time take a request from the sitemap, put it in the repeater and send it to the application, letting Burp take care of cookies, tokens or whatever session management method is - update.

---

## Components of automated session management

In order to be realized, automated session management requires the following components:

- **Session database**: The mechanism for keeping track of the current session.
- **Update Mechanism**: Mechanism for updating the cookies/headers/other (depends on the application) of an HTTP request with the current session information.
- **Detection mechanism**: Mechanism to detect that the current session has expired.
- **Authentication mechanism**: Mechanism for logging in when necessary.

---

## The capability of Burp Suite for automated session handling - Session Handling Rules

Burp Suite has built-in capability to create session handling rules that implement all four aforementioned requirements.

The session management rules can be found in the Burp settings and by default, there is one rule already prepared in the project:

- It is called "Use cookies from Burp's cookie jar".
- It is enabled.
- It is restricted to the Scanner tool only.
- Contains only one rule, which is "Use cookies from Burp's cookie jar".

![](sanity:image-f5ab29f9fc14b2acd6372ffa05f766d49117200c-2784x720-png)

![](sanity:image-a51bd2ae685960f17693d09559fbc726e4c7c6ce-1472x482-png)

---

## How are Burp Suite session management rules built?

Burp session management rules are built upon description, scope, and a series of steps that are executed in order from start to finish, unless the execution is interrupted.

### Description (Rule description)

The session management policy has a description that can be defined by oneself.

![](sanity:image-b8fcf759d57f54825ebf14886bca6c458ea9b13e-1088x382-png)

### Tools scope

Tools scope once again defines to which Burp tools the session handling rules are applied. If you want, for example, the Repeater tool to stay automatically logged in the way you want, set it in the Repeater scope. If it's not in the scope, session handling won't affect Repeater and cookies, etc., won't be updated automatically.

A proxy tool is rarely included in scope, but it also has valid use cases. One typical use case is running a third-party testing tool (such as sqlmap) through Burp, with the idea that Burp will ensure that the session remains valid throughout the entire scan.

![](sanity:image-d57a7818b546569b983b7fd6756cbb245fbdb7bf-1182x406-png)

### URL scope

URL scope determines to which URL addresses the session management policy is applied. Typically, one of the following is used:

- **Use suite scope**: Use this when you have set only those URLs in Burp suite scope to which outgoing requests you want to be processed with this session management rule, and the scope does not have multiple targets, for example.
- **Use custom scope**: Use this when there are multiple targets in the Burp scope and you want the Burp session handling automation to behave differently depending on the target.

There is also an option "Include all URLs", but its use is not recommended due to high risk of damage (sending authentication credentials of the target application to a completely wrong application by mistake).

![](sanity:image-99819f8996934a87918ff2d992cccabd8b762e30-1754x876-png)

### Rules (Rule actions)

The rule consists of individual rules that are executed for each HTTP request within the scope one at a time from top to bottom, until completion or interruption of the execution.

![](sanity:image-52a6ad5f964682d96b9588fe7f1fff4ab5b8d69a-1488x512-png)

- **Use cookies from Burp's cookie jar**: Updates all HTTP request cookies from Burp's cookie storage.
- **Set a specific cookie or parameter value**: Set a specific URL parameter, body parameter, or cookie.
- **Check session is valid**: Checks if the current session is valid.
- Option 1: Infer from the current HTTP request and response.
- Option 2: Run a recorded HTTP request or sequence (Macro) with current session data and infer from it.
- **Prompt for in-browser session recovery**: Prompt the user manually to notify if the session expires so that you can manually log in again.
- **Run a macro**: Run a Macro (which actually is a stack recorded with one or more HTTP requests).
- **Run a post-request macro**: Run after the Macro request.
- **Invoke a Burp extension**: Launch a Burp extension that implements the ISessionHandlingAction interface.
- **Set a specific header value**: Set the value of a specific HTTP header.

![](sanity:image-9629ae1f1381e14664d8cb4234e6accd680889c1-886x672-png)

---

## How do Burp session management rules work?

A typical rule set could work as follows.

- You send an HTTP request with a repeater to the address https://www.example.com.
- Burp checks for enabled session management rules
- Burp checks if there is a rule in the enabled session handling rules that has Tool scope as Repeater.
- Burp checks these rules to see if any of them have a URL scope that is "https://www.example.com".
- If such a rule is found, Burp will start executing its rules. Let's imagine that the rules are as follows:
- Use cookies from the session handling cookie jar
- Tarkista, onko istunto voimassa
- Retrieve the Location header from the current HTTP response for the HTTP request at hand
- Burp updates the cookies of the HTTP request from Burp's cookie jar.
- Burp sends a modified HTTP request to the web server.
- Burp checks the HTTP response and determines if the session is still valid.
- The HTTP response contains a "Location" header that redirects to the login page, which means that the session is not valid.
- Execute a recorded Macro that sends a POST request to the login page with the username and password.
- Take the cookies received from the response and save them in Burp's cookie jar.
- Go back to the first step.

---

## Burp Cookie Jar - How cookies are updated to the jar and where to find the jar?

The Burp cookie jar can be used and updated from the session management rules.

The cookie jar can also be set to automatically update from certain tools seen in Burp's HTTP responses, and the jar can be manually modified and inspected. This is done through Burp's "Sessions" section in the settings.

![](sanity:image-aa9dd65fb80104e6bd5702e962077a92c9632170-1366x512-png)

---

## Check session is valid

This

![](sanity:image-e93ae5a4b4cd70a23a43cf42eb68ea6cd129118a-856x466-png)

---

## Session Tracer tool

Session management rules can become complex and sometimes it can be difficult to say why a rule does not work as desired. For this reason, Burp includes a tool called "Session Tracer" (found in the same "Sessions" section of the settings) which allows you to track the execution of session management rules rule by rule.

![](sanity:image-6e490c12cc32994efc709c0c4f2051c1c97dfd17-1482x192-png)

---

## Practical Example: Tick a Box

Next, we will use a real application as an example and build a functional session management policy! If you want, you can launch the task page at the bottom of this stage and do it yourself.

### Step 1 - Research work

First, you need to figure out how the application identifies the user and manages sessions. After completing the research phase, you will know all four necessary components (session database, update mechanism, detection mechanism, and authentication mechanism).

Let's start by opening Burp's browser and setting the scope appropriately.

![](sanity:image-bc8cd7049a0047e566a2fac0e868201eeaa5a070-1144x444-png)

Let's then log in and examine HTTP traffic with Burp.

![](sanity:image-0229987be24e9160b8897e7dac97776fd4c62c6f-1080x366-png)

![](sanity:image-e3a7ef190fb212e46d2a582fdaf4846055d3446f-1146x924-png)

Login has clearly occurred in the POST request to the /login path.

![](sanity:image-478c0a6649f87071f667fe246b693e728858c88b-1018x340-png)

A request has been made with a username and password. In return, a cookie named session and a redirect to the homepage have been received.

@embed 5c1e7103e62b

The following GET request to the homepage includes the "session" cookie and the response is 200 OK.

@embed cd299f58ba26

Next, let's investigate the detection mechanism for when the session is no longer valid. Send this latest HTTP request to the repeater and send it, ensuring that the response is still 200 OK.

![](sanity:image-e126d7d4c8057afc883a816cc229ac0a18641c88-1466x410-png)

![](sanity:image-7be581cad2a3d75b215cfebf3ad6669336797d1b-1154x278-png)

Now logging out of the application (which typically expires the session) and sending the same request again. Let's see what happens.

![](sanity:image-eb64e6d13175e1f3dc6e558bdf10e8c632c816e0-1234x308-png)

The response is no longer 200 and contains a redirection to the login page in the **Location** header. **Redirecting to the login page is often a great way to identify an expired session**.

Let's reiterate the components:

- **Session database**: Used to store the currently valid **session** cookie in Burp's cookie jar.
- **Update mechanism**: Uses the** "Use cookies from the session handling cookie jar"** rule to update the current HTTP request by replacing the value of the **session** cookie with the one stored in the cookie jar.
- **Detection mechanism**: Used "Check session is valid" rule to always read the response of an HTTP request and deduce an expired session from the **Location** header containing the word "*login*".
- **Authentication mechanism**: Used for "Check session is valid" reauthentication if the detection mechanism determines that the session has expired. This is done by recording a macro that sends a POST request to the /login path.

### Step 2 - Building Session Management Policy

Open Burp settings and go to the "Sessions" section.

#### Cookie container configuration

As mentioned, Burp can automatically update the cookie jar based on HTTP responses detected in various tools. However, we do not want this to happen uncontrollably, as otherwise browsing the application through Burp's proxy could interfere with an ongoing scan or intruder run.

If "Proxy" is checked, then remove it.

![](sanity:image-272ca388a49dfee59785efcad7d808b92895ef28-1360x492-png)

Now we have the session database ready.

#### Removing default rules

Removing the default ruleset completely and creating a new one. So click on "Remove" to make the list empty.

![](sanity:image-8e5645dd0a731e053bc86f789d56166ea4e79517-1300x668-png)

#### Create a new rule

Create a new rule using the "Add" button. Give it a description, such as "My session handling rules".

![](sanity:image-6f7748d49789e302bdfaeef933b4e1594a00b269-1128x404-png)

#### Set scope

Then open the "Scope" tab and add the "Repeater" and "Intruder" tools to the scope.

You can choose "Use suite scope" for the URL scope. However, please note that you need to have the target URL address added to the scope as discussed earlier in the course.

![](sanity:image-8b78f1641c428ee067e913231879ef15144a5dd5-1130x800-png)

#### First rule - Using cookies from the Burp cookie jar

Add rule "Use cookies from the session handling cookie jar". This always updates the cookies of the HTTP request in scope from Burp's cookie jar.

![](sanity:image-e908b16ac8e3279a0db5e556f8c15a485ddaff33-1086x474-png)

You can at this stage restrict which cookies you want to update. You can leave these blank and all cookies will be updated.

![](sanity:image-9e5657e1a9008b403a4a1125f5f889d71b55620f-1504x342-png)

Now we also have the update mechanism connected. We still need the detection mechanism and the authentication mechanism.

#### Second Rule - Session Validation

Add the rule "Check session is valid". There is some tinkering to do in this box, let's go piece by piece.

![](sanity:image-15e1002d9bd1e9f550006cd753175536812ba85c-1006x508-png)

![](sanity:image-37c62fad195e870908f1895058cad05d3f3ddf04-1144x604-png)

**Make request(s) to validate session**: The first step is to:

- **Issue current request**: Determine the session state from the current HTTP request's HTTP response (instead of sending a completely separate HTTP request. Sometimes this is necessary, but not now).
- **Checking the situation for each HTTP request:** That is, leave uncheck "Validate session only every N requests".

![](sanity:image-20ec8378c7de64f5d727fdc1c45d61b749d37781-1090x684-png)

**Inspect response to determine session validity**: Then select that:

- **Location(s)**: URL of the redirection target, in other words, the information of interest to us is located in the HTTP response header Location.
- **Match type**: Literal string (so not a Regex pattern, although that can sometimes be desired).
- **Case-sensitivity**: Letter case does not matter.
- **Match indicates**: Invalid session, which means that if there is a hit similar to the described one in the HTTP response, it means that the session is not valid. This could be done reversely if it is easier for the specific application.

**Define behavior on session validity**: Next, choose that:

- If session is invalid, perform the action below (If the session is not valid, do the following):
- Run a macro (Execute Macro)

Then you need to record the Macro.

#### Recording Macron

Click "Add" to record a new Macron.

![](sanity:image-d1bc5674a3f5a6b5d52079df77d1c401060bb713-1062x414-png)

![](sanity:image-4bb40e6701e3599cc816261d9ba58b9a8b480fd0-1988x826-png)

The opening view is essentially only HTTP proxy history. The view updates in real-time as you make more HTTP requests through Burp.

Before recording a macro, it is generally advisable to log out of the application and clear your browser's cookies and other data. This way, you will be able to record a clean starting state for the macro.

![](sanity:image-a64ac1ca432331e4998e3653bcb9292c6bce909d-510x98-png)

Then you can update the application page and log in. This should generate at least:

- One GET request without cookies (in the Cookie header of the HTTP request) but with a session cookie returned in the Set-Cookie header of the HTTP response).
- One POST request to /login page with a session cookie included (in the HTTP request Cookie header) and the response is a 302 redirect to the homepage.

![](sanity:image-688edb5a6ea2d9534f1718c97f4c4089f882ddaf-1870x100-png)

Select these two HTTP requests from the list. The order matters. Press "Ok".

![](sanity:image-5f9e3da86ceac6e2b8d9eaff87fc3b00f5f5f9d3-1162x130-png)

Name the Macro "Login". Do not click "Ok" yet because the Macro needs to be both configured and tested first.

![](sanity:image-a0942cad8512c80ceec48ce2f12187a2c49074df-1284x524-png)

Select the first HTTP request from the list (GET request without cookies) and click "Configure".

It is important not to use cookies from the cookie jar in this HTTP request in the future, so that an expired cookie is not accidentally used when trying to log in again.

Leave a checkmark on "Add cookies received in responses to the session handling cookie jar" because it is necessary to immediately save the "session" cookie returned by the application on the first page load.

Instead, uncheck "Use cookies from the session handling cookie jar" because the purpose is to create a fresh, clean login and not use old cookies.

![](sanity:image-71d2ef3937311d5862b369279462dc04acd32c7c-1258x416-png)

Press "Ok" to finish.

Test the following Macro next.

![](sanity:image-094fa6c06054b6421921a532da2f7c5ae3ac539d-700x308-png)

If everything goes well, the last HTTP message of the test sequence should contain a redirect to the homepage.

![](sanity:image-bc57bac9a94754bd562a8af20cced4cdc5577658-1504x470-png)

![](sanity:image-06f1e0682ec41700a805e832af0dd5985270299f-398x88-png)

Click "Ok" and "Ok" to return back. Macro is now recorded and set to run if the session is no longer valid.

![](sanity:image-cb1b8a09d6606ec8b8dc6472ead7d752ef31b425-1206x530-png)

Finally, just check the boxes for "Update current request with parameters matched from the final macro response" and "Update current request with cookies from session handling cookie jar".

![](sanity:image-6147928a125195891a888ed1e7916b32d932c429-1648x738-png)

Click "Ok" and "Ok". Your policy is ready.

![](sanity:image-5a0b1986adf3ee38ff1197f0917168ab4a110923-1120x420-png)

#### Testing the Regulations

Login to the application and click on one of the checkboxes. Take a look at the HTTP message that the click leaves behind and then send an HTTP request to the repeater.

![](sanity:image-e51d020e9ab7d033f6b1e3977a4b9adc6e52a5ab-1236x376-png)

Send the request with a repeater. Try removing the entire cookie and send the request again with a repeater.

If the rule set is working, the cookie magically reappears on every new HTTP request and the HTTP request goes through.

![](sanity:image-86e92b1259af07250eb6a88cefe51a2f85749d55-926x240-png)

#### Debugging the rule set with session tracer

You can debug the problem or simply confirm that the rule set is functioning as expected using the aforementioned session tracer tool. Click "Open sessions tracer".

![](sanity:image-0c325dea9b9f538733c2a386ecba0029bfb7df64-1258x354-png)

The view is always initially empty.

![](sanity:image-538aff8e25fd54496174f48a7d5d96c542cd9b4d-1364x534-png)

Send a message with Repeater. Then check the session tracer.

![](sanity:image-f3f4c89067bbdc7a9a3021e1567f55b4f05c51f7-2008x1354-png)

You should see that:

- Rules and regulations are used
- Checking if the session is valid
- Notice that it is not valid
- Run Macro "Login"
- Add a cookie to the cookie jar
- Sending updated HTTP request

---

## Session Management Extensions ("Invoke a Burp Extension")

In this module, we do not discuss the creation of custom extensions, but briefly, these can be done with Java or similar languages like Python, enabling more versatile handling of various scenarios. Unfortunately, it is not possible to automate every application's login and session management solely with Burp's pre-built tools.

---

## Practice

Start the "Tick a Box" application from here and complete the task.

@exercise d67a87206d84


Ticking boxes 2

BurpSuite - Session Manager

BurpSuite is the leading web application security tool that facilitates identification and exploitation of vulnerabilities in web applications using various tools.

BurpSuite is a leading web application security tool that facilitates the identification and exploitation of vulnerabilities in web applications through various attack tools.

BurpSuite - Session Manager

Learn to hack — start here