Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

CSRF attacks disrupting testing flow

Sam | Last updated: Dec 15, 2017 10:54PM UTC

I am having trouble using Burp with my application's CSRF defenses. I can get around these problems by disabling a few features, but I am concerned that I may be approaching this problem the wrong way. My application defends against CSRF attacks by (1) checking the Origin and Referer headers and (2) using the double-submit cookie pattern. (I.e. we submit a CSRF token in the cookie and form parameter with each request.) If we identify a potential attack, we log a security incident and log out the user. Our application flags Burp's CSRF attacks, which is good. But then our application logs out the user, which is very disruptive to the Burp testing. All the queued attacks will fail because the user is not logged in, and it's not realistic to perform a login request for each action on the site. I was able to get around this problem by changing the following Burp options (on Scanner > Options): - Disable "HTTP headers" under the "Attack Insertion Points" section - Disable "HTTP header injection" under the "Active Scanning Areas" section - Disable "Cross-site request forgery" under the "Active Scanning Areas" section - Skip all tests for our CSRF token cookie - Skip all tests for our CSRF token body parameter This configuration seems to work at the moment, but I am concerned that I am disabling a lot of valuable tests. Is there a better/more effective way to test my application using Burp?

PortSwigger Agent | Last updated: Dec 18, 2017 07:59AM UTC

Hi, Thanks for your message. Testing applications like this can be tricky, especially with an automated scanner. Your approach sounds quite reasonable, especially if you manually test the CSRF token. As an application-wide defence, you only need to test it in one place, to have confidence that it's resolved across the application. Another approach is to use a session handling rule. First, record a macro to perform a login. Then, create a session handling rule with the action "Check session is valid". You need to tell it how to inspect responses to check for a logout. Often applications will redirect you to the login screen when, and you can configure the rule to check for this. Then configure it to, if session is invalid, run the login macro. To check your rule is working, you can use the sessions tracer. Please let us know if you need any further assistance.

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