Juggling Application Tokens Using Burp Suite’s CSRF Token Tracker Extension
By Karl Schuttler | January XX, 2024 | Application Security
(Karl generated using OpenAI - he’s missing a couple fingers but he can still juggle tokens!)
Most applications use some form of Cross-Site Request Forgery (CSRF) token to prevent external sites from coercing their visitors into unwittingly executing malicious functions. Application Pentesters must routinely identify and handle these tokens so that their scans can successfully execute. Testers should perform a quick sanity check of each Burp Suite scan that they launch, using the Logger tab to validate that the scanner requests are not failing due to a missing CSRF token or other requirement. Testers that “fire and forget” automated scans will have false negatives when Burp is unable to detect the application’s token logic.
Burp Suite comes with some sophisticated session management tools, but it’s often easier to configure extensions rather than try to get things done with Macros. The CSRF Token Tracker extension is a great extension for scraping and replacing token objects, particularly when handling rotating tokens. In this article, we discuss how to properly configure the CSRF Token Tracker extension.
We are working with one of Oracle’s PeopleSoft web applications for an example. PeopleSoft applications use two different CSRF tokens for unauthenticated (i.e., login portal) and authenticated internal access. The internal CSRF token is submitted in the “ICSID” parameter, and refreshed by the server as needed within a hidden input field. On pages that perform GET (read) operations, the token is static. The token is rotated when an update or write operation is executed using a POST request.
The screenshot below shows an authenticated interaction. As the value of the updated ICSID token provided by the server is the same as was submitted, we know that this was a read operation.
The CSRF Token Tracker extension is nice because it is very simple to use. Fill out the extension’s table with the Host header value of the application, and the Name of the token parameter (“ICSID”). In the case of our example application, the Name of the token is the same in both the request and response, so we are done. Once we click both checkboxes to “Sync requests based on the following rules” and Enable our new rule, the Value field will populate on the next response and it will begin performing token juggling for Burp’s tools.
The position of the submitted token might be different than from where CSRF Token Tracker extracts it. For example, some webservers require the token to be included within an X-CSRF-Token header, or within a browser cookie. CSRF Token Tracker is capable of passing tokens to different header positions within requests by providing them within the Name(Req) field.
The following screenshots show a configuration that extracts the token from the response’s hidden “ICSID” HTML input tag and includes it within the SignOnDefault cookie of requests. Requests that have been modified using CSRF Token Tracker follow Burp Suite’s convention of marking the request as “Edited”, providing confirmation that the sync is executing and allowing the unmodified request to be inspected..
If you’re looking to perform this kind of token juggling with multiple user roles during interactive Authorization testing, consider reading our blog on performing Authorization testing using AuthMatrix extension chains. If you need to perform more dramatic transformations to the token or sculpt the request in an unusual way (e.g., process using an external tool), check out our blog on performing complex transformations using the ReShaper extension.