Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Burp scanner: how to add support for csrf tokens

Lee | Last updated: Sep 23, 2016 12:23PM UTC

I'm having an issue with the Burp Scanner: when anti-csrf tokens are present, it seems the scanner cannot handle it and it faild to perform active/passive scans. Would it be possible through Burp Extension capabilities to add a feature so Burp checks each requests, extracts the CSRF token, and adds it to the submittion request? Thanks,

PortSwigger Agent | Last updated: Sep 23, 2016 01:36PM UTC

You can use Burp's session handling rules to deal with many situations where CSRF tokens are used: https://portswigger.net/burp/help/options_sessions.html Also, there is an extension in the BApp Store that says it can automatically handle CSRF tokens: https://portswigger.net/bappstore/ShowBappDetails.aspx?uuid=086c6af8b24c40a79a5e99b71df10f11

Burp User | Last updated: Sep 26, 2016 01:48PM UTC

Alright I'm trying to use the Macros to resolve my issue. I have currently two parameters that I need to extract: When I first request the login page I need to extract a parameter named loginToken, that I will pass when login into the application alongside with the username and password. Once logged, a csrftkn on the header are taken from the login response when successful I have setup the 2 macros and the parameters to extract, however I'm not sure the scanner is using them as it seems the responses are redirecting to the authentication page. How can I check the extracted parameters and pass the parameters to the first macro to the second one? Thanks,

PortSwigger Agent | Last updated: Sep 26, 2016 02:07PM UTC

Burp's automatic updating of parameters using macros works for conventional request parameters (in the URL query string or message body). It doesn't work on custom request parameter locations, such as headers. If the parameter you need to update is in the URL query string or body, then you just need to ensure that Burp extracts the relevant value from a macro response. For things like form fields and query string in links, Burp will do this automatically. If the response contains the parameter value in a nonstandard location like a response header, you will need to define a custom parameter location within that response, and give it the same name as the subsequent request parameter in which it is used.

Burp User | Last updated: Oct 03, 2016 01:39PM UTC

Ok so I have added two macros (following our first link on sessions), and for some reasons Burp doesn't update the initial requests he send when performing an active scan. For example, if for one day I'm navigating through the application, and on the next day I'm going to launch the scanner, the parameters used to check the validity of the session (typically JSESSIONID) are not updated because the scanner is automatically logged out. So it looks the initial request is not updated with the last active session values. Is the initial request sent whithout any modification at all (not even cookies for example)? The strange thing is that based on the link on sessions, it should be able to login again and recover the cookie and anti csrf token with the two macros I have defined, but it's not the case. Thanks for your help,

PortSwigger Agent | Last updated: Oct 03, 2016 02:22PM UTC

In the configuration of your macro, you can click on "Configure item" to show options for the handling of each individual item in the macro. By default, the option to use cookies from the session handling cookie jar is enabled, meaning that Burp will update the macro request based on the current contents of the cookie jar. Note that this will only achieve anything if the cookie jar actually contains the value of a valid session token, which won't be the case if you have resumed scanning after a long interval. It is best to run your session recovery macro from a "clean" state with no session cookies, and perform the login and any other steps that are required to obtain a valid session.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.