Updating Anti-CSRF Tokens in Burp Suite

Burp Suite developed by Portswigger, is the leading software for web application penetration testing. This application is a wonderful tool for fuzzing and automatically scanning HTTP requests to identify application-level vulnerabilities. Performing a web application penetration test against a target application that has developed a strong defense against Cross-Site Request Forgery Attacks can be frustrating. This is due to the fact that the application is built in a fashion that does not allow a request to be repeated without updating the anti-CSRF token. While several other software solutions in the web application security realm allow for the automatic updating of anti-CSRF tokens, Burp Suite currently does not support this functionality without being configured to do so, which can be a rather tedious task. In this blog post we will review how to configure a Burp Suite macro and configure the session handling rules to automatically retrieve an HTTP response, extract the anti-CSRF token, and then insert that token within the subsequent HTTP request.

For this example we will use an inherently vulnerable web application called DVWA. A copy of this app can be found at http://www.dvwa.co.uk/.

We have DVWA configured on an internally reachable virtual machine.

First, let’s review what we are trying to accomplish here.

 

 

Upon entering our credentials and submitting the form, the HTTP request sent to the server possesses the anti-CSRF token.

If the value of the ‘user_token’ parameter received by the web server does not match the value expected, the request will not be considered valid.

This can be problematic when attempting to scan or fuzz requests because a new token needs to be obtained from the server each time a request is made. Now let’s dive into how to tackle this problem by creating a Macro in Burp Suite and configuring the Session Handling Rules.

Creating a Burp Suite Macro:

1. Navigate to the ‘Project Options’ tab in Burp Suite and select the ‘Sessions’ tab.

 

2. Scroll to the bottom and click ‘Add’ in the ‘Macros’ section:

 

3. The ‘Macro Recorder’ will pop-up, which contains your HTTP history. At this point, you’re going to want to sort by ‘Time’ so that you can select all the requests necessary. Highlight both the HTTP Messages associated with the anti-CSRF token and click ‘OK’ at the bottom of the window.

 

4. Highlight the request that possesses the anti-CSRF token within the HTTP response returned, then select ‘Configure Item.

 

5. Now, we want to configure a few things including the ‘Parameter name’, ‘Start after expression’ and ‘End at delimiter’ fields.
Add a value in the ‘Parameter name’ field. To keep things simple, we will use the actual parameter name which is ‘user_token’.

Now we want to configure the ‘Start after expression’ field to everything from the beginning bracket of the input field in the HTML up until the parameter’s value. In this scenario, that value would be <input type=’hidden’ name=’user_token’ value=’.

Lastly, we will auto-configure the ‘End at delimiter’ field by simply selecting and highlighting the anti-CSRF token in the body of the HTTP response.  Configuring the ‘Start after expression’ and ‘End at delimiter’ fields can be automated all together by simply highlighting the value you want to extract.  The problem with this is that Burp will insert a non-unique string in the ‘Start after expression’ field.  Therefore, I find the best approach is to simply highlight the value you would like to extract and then simply copy and paste a more unique value in the ‘Start after expression’.

 

6. After clicking ‘OK’ twice, we want to configure the second item, which is the HTTP POST request that sends the anti-CSRF token to the web application. In the ‘Parameter handling’ section, you will see all the POST parameters the request possesses. We want to configure all parameter items to ‘Use present value’, except for the parameter that possesses the anti-CSRF token that we want to update. The anti-CSRF token parameter should be set to ‘Derive from prior response’.

 

7. After clicking ‘OK’, we need to assign the macro a name in the ‘Macro description’ field.

 

8. At this point, we simply want to test the Macro. In the lower right-hand corner of the ‘Macro Editor’ click the tab ‘Test Macro’. After the macro runs, review the value present within the anti-CSRF token parameter in the HTTP POST request. Then, click the ‘Retest macro’ button and review the value again to ensure that the two values observed are unique. If the two values are not unique, then go back through the process and identify what went wrong, otherwise click ‘OK’ twice to save the Macro and close the ‘Macro Editor’.

Configuring the ‘Session Handling Rules:

1. Under the ‘Session Handling Rules’ section, click the ‘Add’ button.

 

2. Name the session handing rule something convenient in the ‘Rule Description’ section. Then click the ‘Add’ button, under the ‘Rule Actions’ section. Click the ‘Run a post-request macro’ in the drop down.

 

3. In the pop-up window, select the macro you want to run. Then ensure the box is checked for the ‘Update the first macro request with parameters matched from the response to the current request’ option. Then select the radio button for the ‘Update only the following parameters’, click ‘Edit’ and add the parameter you want updated. Lastly, we want to check the radio button under the ‘Pass back to the invoking tool’ section, for the ‘The final response from the macro’ option. Click ‘OK’.

 

4. Click the ‘Scope’ tab. Under the ‘Tools Scope’ section and select the tools you want the rule to be applied to. Add the ‘URL Scope’, I typically add the target application to the suite scope and find that option most convenient. Otherwise you can manually configure the scope to match your preference. Lastly, in the ‘Parameter Scope’ section, select the check box for the ‘Restrict to requests containing these parameters’ option, click the ‘Edit’ button and again add the anti-CSRF token parameter to the ‘Edit list’. Then click ‘OK’

 

Spinning the tires:

Now we want to test out our configuration to see if everything is running smoothly. To accomplish this I typically use Intruder because it’s easy to evaluate each request to determine if the POST parameter that possesses the anti-CSRF token is being updated. Use the Proxy to intercept the POST request, send the request to Intruder, select a static parameter and run a simple fuzz list against it. If the anti-CSRF token parameter is being updated within each request, then you are all set to go.

Originally authored by Ryan