One of the reasons that Burp Suite has become a standard tool for Web Application Penetration Testing is the ecosystem of Extensions that enable it to support new functionality. Sometimes these extensions only have partial adaptability, and need additional support to gel with the unique requirements of the application. For example, when security tokens (e.g., CSRF tokens) are submitted in unconventional locations, are set on a per-function basis, or require external processing in another tool.
In this blog post, we continue our previous discussion about the Reshaper plugin and show how Reshaper can also be used to enhance existing extensions. This post will be particularly useful for testers who encounter applications using security tokens (e.g., CSRF tokens) in unique manners, where they may require transformation that Burp’s scanning engine and existing plugins do not support. If you’ve reached this post looking for guidance on how to perform automated authorization testing for more than two roles simultaneously, or just need to support CSRF tokens in a more typical use case, consider reading our Blog post on AuthMatrix chains.
The Autorize extension is a straightforward extension for automated Authorization testing using two roles. As seen below, the extension allows the user to set the “Temporary Headers” field with Cookies or Authorization header values for a low-privilege account. The application is then accessed using a high-privilege account within the browser. All requests made through the browser will be duplicated using the altered headers, and the extension will provide visual details about whether the lower-privilege account was able to successfully execute any high-privilege functions:
This workflow is simple and effective. Unfortunately, the Autorize extension does not support any configuration options to extract Cross-Site Request Forgery (CSRF) tokens, so applications that use rotating tokens will not be able to be tested using Autorize. When Autorize automatically submits the lower permissioned user’s request, it will fail when the application server rejects the stale CSRF token:
Throughout the rest of the article, we will discuss the configuration of the Reshaper plugin to add support for rotating CSRF tokens, providing an example of how Reshaper can be used to make modifications to existing extensions.
To get Burp’s traffic flowing properly between multiple extensions, it is critical that they be arranged in proper load order. Burp Suite routes requests through loaded extensions based on their order within the Extensions tab. To make sure that the duplicate requests submitted by the Autorize extension reach the Reshaper plugin, it must be before Reshaper, so use the “Up” button to place it at the top of the list:
Next, we need to identify the application’s CSRF token behavior, and then decide how we want to implement it within Reshaper. The sample application we are working with sets a Cross-Site Request Forgery token within a meta tag located on application pages that have submittable forms. The tag also appears in the server’s response after the token is used, refreshing it with a new value. Thankfully, it is included within the same HTML hierarchy on every application page:
The application requires the token to be submitted within the X-Csrf-Token header for all functions using POST, PUT, UPDATE, and DELETE verbs. Generally, it’s required for anything that sets a value or executes some kind of state change, but not read-only operations (GET). The Cookie header is redacted in the following screenshot illustrating the submission:
Reshaper gives us all kinds of ways to accomplish our task, including the ability to call the command line and read and write to the filesystem, but it’s always important to try to work efficiently within the extension. Try to always minimize the requests and responses that you are processing within Reshaper to reduce its overhead, and only call external applications if it’s absolutely necessary. Inefficient Reshaper rules can quickly get your processor cranking and slow down your testing.
To achieve our initial goal of getting Autorize to work, we’re going to develop our first Reshaper rule which will identify requests using the X-Csrf-Token header, and then inject the value of a stored variable (the CSRF token) into them.
Following our desire to reduce Reshaper’s overhead, we’re going to set our new rule’s first “When” condition to only operate on requests coming from Extender. This way, Reshaper will only process requests coming from Autorize. Let’s start our new rule. [From Tool: Extender]
Next, we’ll set it to operate on Requests, because we need to inject the token into requests. [Event Direction: Request]
Finally, we only want to work with calls that already have the X-Csrf-Token header in them. [Matches Text: X-Csrf-Token]
All we need to do now is to set the value of the X-Csrf-Token header to the low-permissioned user’s CSRF token. We only need a single “Then” condition for this. [Set Value: Request Header]
Set Value takes Reshaper’s token global variable, referenced by “”, and places its value in the X-Csrf-Token request header.
We still need to retrieve the new CSRF token value each time it updates.
Our application uses OAuth with Multi-Factor Authentication, and has a two-hour session maximum, so we’re going to have to manually log in every two hours no matter what. Luckily, the application automatically loads the /configSettings page after login, which contains the initial embedded CSRF token. This means that we can easily prime Reshaper with the token immediately after the login process, and then begin our testing session.
Let’s create a new rule. First, we identify traffic from Autorize. [From Tool: Extender]
Next, we only work with Responses, since they contain the token we need to save. [Event Direction: Response]
Finally, we only work with traffic that matches our CSRF token HTML tag. [Matches Text: meta name=\”csrf-token\”].
Now we just need to retrieve the token’s value from the page. We’ll do this with two Set Variable “Thens”. The first Set Variable action operates on the Response Body containing the CSRF token HTML and uses the Source Value Path feature to specify its location. The appropriate value can be retrieved by selecting the HTML tag within the browser’s Developer Tools, and using the context menu to “Copy selector”.
This is pasted in the Source Value Path field within Reshaper.
As you can see above, we also use the Regular Expression (Regex) Replace feature to strip away the beginning of the CSRF token’s meta HTML tag. We save it into the token global variable.
As seen below, the second Set Variable operation is just used to remove the end of the HTML tag from the token variable.
We can now log into the application and configure Autorize after authenticating in two browsers, one for the high-privilege user and one for the low. Input the low-permissioned user’s Cookie header in the “Temporary headers” field and turn Autorize on.
Browsing to the homepage within the high-privileged user’s session will initiate the call to /configSettings, priming Reshaper with the initial low-privilege CSRF token. The Reshaper token injection rule may be enabled, and the Autorize testing session can begin.
When we started, the application was failing CSRF validation when Autorize submitted stale values, preventing us from performing Authorization testing. Now the application responds appropriately back with HTTP 401 Unauthorized errors when Autorize tries to execute functionality that the low-privilege user shouldn’t be able to access (e.g., edit Admin settings). If it allowed the action and returned HTTP 200, then we would have found a new authorization bypass vulnerability.
While this type of Reshaper workflow is useful for Authorization testing, it can also be configured to act on Burp Scanner traffic for Injection testing. Scanner would otherwise be submitting stale CSRF tokens too! This is a great reason to always view the first few requests of any executed Burp scan and confirm that your requests aren’t failing due to some application requirement that is not being satisfied.
If you’re interested in learning more about automated Authorization testing, consider reading White Oak Security’s Blog on using the AuthMatrix extension. The second part of that article discusses the use of AuthMatrix’s “Chain” feature, which may be similarly configured to extract and use changing identifiers like CSRF tokens.