The session handling rule editor lets you configure all the details of a session handling rule.
This provides a free-form text field in which to describe the rule. The description will appear in the ordered table of configured rules.
Each rule can specify one or more actions to be carried out. When the rule is applied, these actions will be performed in sequence, unless one action determines that no further actions should be applied to the request. The following types of actions are available:
All of these actions are highly configurable, and can be combined in arbitrary ways to handle virtually any session handling mechanism. For example, being able to run arbitrary macros (defined request sequences), and update specified cookie and parameter values based on the result, allows you to automatically log back in to an application part way through an automated scan or Intruder attack. Being able to prompt for in-browser session recovery enables you to work with login mechanisms that involve keying a number from a physical token, or solving a CAPTCHA-style puzzle.
This action updates the request with the relevant cookies from Burp's cookie jar. You can configure the action to update all cookies (optionally, with specific exclusions), or only to update certain specific cookies.
This action updates the request and sets a specific value in a named parameter or cookie. If it is not already present, you can specify the type of parameter that should be added.
This action checks whether the current session is valid, and if not, optionally performs a further action to obtain a new valid session.
To determine the validity of the current session, Burp issues one or more requests. It can either:
If the current request is issued, and the rule determines that the session is valid, then no further actions can be performed on the current request.
Optionally, you can configure Burp to only validate the session every X requests. This is useful to avoid making superfluous requests in cases where the application only rarely invalidates your session.
Having made the configured request(s), Burp examines the response to determine the validity of the session. If a macro was run, then Burp examines the response from the final request in the macro.
To determine session validity, Burp checks whether or not the response contains a specified expression. Burp can be configured to search:
The search can be configured to use a literal string or a regular expression, and can be case sensitive or insensitive.
You can configure how Burp behaves, dependent on the validity of the session.
If the session is valid, you can specify that Burp should not process any further rules or actions for the current request. This option is mandatory if Burp is configured to validate the session by issuing the current request.
If the session is invalid, you can specify that Burp should perform one of the following actions, to obtain a new valid session:
This action causes Burp to prompt you to recover a valid session using your browser. The browser must be configured to use the same instance of Burp as its proxy, so that Burp can monitor your browser's requests, and any new cookies that are set.
The cookies set by the application will be added to Burp's session handling cookie jar, and optionally can be updated in the current request. You can configure the action to update all cookies (optionally, with specific exclusions), or only to update certain specific cookies.
This action runs a predefined macro (sequence of requests). Macros are defined separately within Burp's session options, and are available to be used within session handling rules.
After running the macro, Burp can optionally update parameters and cookies in the request currently being processed, based on the final macro response.
Parameters in the current request can be updated using values derived from the final macro response. The derivation of parameter values works in the same way as for macro parameters generally. For derived parameters, the following options are available:
For both parameters and cookies derived from the macro, you can configure the action to update all items in the current request (optionally, with specific exclusions), or only to update certain specific items.
This action issues the request that is currently being processed, and then runs a further macro (sequence of requests). Macros are defined separately within Burp's session options, and are available to be used within session handling rules. After this action has been performed, no further rules or actions will be carried out on the request that is currently being processed.
Post-request macros are useful if the request you are testing appears within a multi-stage process, and you need to step through the remaining stages to update the application's state and determine the effects of the request you are targeting.
After issuing the current request, Burp can optionally update parameters in the first macro request, based on the response to the current request. The derivation of parameter values works in the same way as for macro parameters generally. You can configure the action to update all parameters in the first macro request (optionally, with specific exclusions), or only to update certain specific parameters.
You can configure the action to pass back to the invoking tool either the response from the current request, issued prior to executing the macro, or the final response from the macro. The latter option is useful in cases where you are scanning or fuzzing input at one step in a multi-stage process, and any resulting error message is displayed at a later step in that process.
This action invokes a Burp extension to process the current request. The extension must have registered a session handling action handler. You can select the required handler from the list of available handers that have been registered by currently loaded extensions.
You can specify which Burp tools each rule should be applied to. A rule will only be processed for requests made by tools that are included in the tools scope.
For more details, see help on configuring URL scope.
You can optionally specify that the rules should only apply to requests containing specific named parameters. For example, this setting is useful for an application-wide rule affecting all requests containing a certain parameter that needs to be updated, such as a CSRF token.