Automated scanning with Burp despite Anti-CSRF token
The usage of security tokens in Web Applications is increasing rapidly, especially as more and more frameworks support this technique to prevent CSRF attacks. These anti-CSRF tokens are typically used when state-changing actions are executed, like adding a user or confirming your purchasing order.
There are web applications that use anti-CSRF tokens in the whole application. This makes the web application very robust against CSRF attacks, but makes the life of a penetration tester much harder because automated scanning becomes a nuisance.
This tutorial explains how to circumvent the anti-CSRF tokens used in requests, to execute tools like the Burp Intruder, Burp Active Scan and sqlmap.
If you want to fuzz a certain parameter in a request that is protected by anti-CSRF tokens there is an easy solution already implemented within Burp.
Just send the request you would like to analyze to the Intruder. Clear all payload positions and only select the value of the anti-CSRF token parameter and the value of the parameter you would like to be analyzed by the Intruder. Also set the attack type to Pitchfork.
In the options tab of the Intruder , the number of threads must be set to „1“, as the attack has to be executed as sequential processing. Otherwise the intruder will mix up valid and used anti-CSRF tokens.
To circumvent an anti-CSRF token in the Intruder, it is sufficient to go to the options tab, click on „Add“ in the Grep-Extract menu and choose the value of the anti-CSRF-token in the „Define extract grep item“ menu. The start and end point will be filled out by Burp automatically after selecting the token and we can click OK.
In the Payloads tab, we now need to select the payload type „Recursive
grep“ for the identified anti-CSRF token parameter in the position tab. It is important that you also insert the token that was sent in the last valid response to be used as initial token value for the first request. The second payload can be set to whatever we want to test for.
If we start the Intruder now, the parameter can be tested and the initial token is used to create a valid request. The token in the responses to that is extracted by the grep-rule and inserted into the subsequent request.
In case of an error it is likely that the initial token was wrong or was already used. Then, in our browser, we again navigate to the function we would like to test, execute all of the above steps and use the token of the last response of the application in the initial payload field.
There is also an extension available for Burp Intruder to circumvent this kind of anti-CSRF token:
(1) Burp Extension available to extend Intruder:
Sometimes during testing we encounter applications that already use anti-CSRF tokens during login and for every subsequent request in the application. To automatically scan a certain request in such an application, we have to:
- Get the Login-Page,
- Login to the application,
- Navigate to the function that should be scanned and
- Get the anti-CSRF token that can be used for an automated scan.
Steps 2, 3 and 4 always need the valid token of the last response, otherwise the requests will be invalid. To use tools that execute automatic scans like the Active Scan in Burp or sqlmap, we need to create a session handling rule and a macro to automate the steps (1) to (4) within Burp
We give the Session Handling rule a unique name and select „Run a macro“ in the rule actions section.
To create a new macro we click on „Add“ under „Select macro:“ in the next menu. The macro recorder will start, where we can select the appropriate requests. We must start with a request that does not need a valid token when sent to the application and select all requests until we get to the request we would like to test.
In our case we needed to start at the login, as all other requests needed a token when sent to the application. The first request gets the login page where no token is required. The second request is a login request with valid user credentials, and the third request directs to the page we wanted to test. To get a valid request chain, the second and third request needs the hidden token of the response before.
We can achieve this by selecting the second request and clicking on „Configure item“. There, we set the parameter that contains the token to be „Derive from prior response“. Usually this setting does not work by itself, we also need to „Add“ a custom parameter. We just select the location of the token value and use the parameter name as name for the custom parameter. This must be done for all subsequent requests.
In the „Session handling action editor“ the anti-CSRF token parameter that needs to be updated should be added explicitly.
The scope of the session handling rule should be set to „scanner“. To limit the macro to certain requests we can either use „Use suite scope“ or „Use custom scope“. It is not recommended to set „include all URLs“, as every request in the scanner would then trigger the macro.
After the Session Handling rule is created we just need to enable it. As the macro navigates to the page we want to test and gets a valid token for the scanner, you can execute an active scan of this page now. For another page we would need to create a separate macro.
Every single scanner request will also trigger all the requests we defined in the macro additionally. In the case described above 100 requests of the active scanner would produce 400 requests in total, as every request requires the three requests in the macro. Therefore, the scan will take longer but will also produce more load on the server as many logins will be simulated. So, we should be careful to not overload the server during testing.
The exact same steps as for the Burp Active Scan can also be executed for sqlmap.
There is just one difference: The scope of the session handling rule should be set to „proxy“. But use this setting with caution, as every request in the proxy will trigger the full macro and thus all requests in it. To limit the macro to certain requests here, it is even more important to set „Use suite scope“ or „Use custom scope“, as described above.
When the Session Handling Rule is activated we can start sqlmap. If we have a POST-request saved to a file we can use:
./sqlmap.py -r request.txt –proxy=http://127.0.0.1:8080
If we have a GET-request we can use:
./sqlmap.py –u „www.target.com/vuln.php?id=1“ –proxy=http://127.0.0.1:8080
The NinjaDVA is our comfortable and flexible training environment.
Is your web application vulnerable to SQL Injection? With sqlmap you can test it.
CSRF Countermeasures #1: One possibility to prevent CSRF is the usage of an anti-CSRF token.
CSRF stands for “Cross-Site Request Forgery” and is a classic among web application attacks. With this attack, it is possible to perform certain user actions without them noticing it. But how exactly does this attack work?
At the it-sa 2019 we will present our innovative consulting concept Lean Application Security.