Research Academy
My account Customers About Blog Careers Legal Contact Resellers
The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

Burp session handling in multiple scanner threads

Zach | Last updated: Sep 30, 2015 03:15PM UTC

Hi all, I just wanted to know how burp handles in-session detection and subsequent macro execution while scanning using multiple threads. Suppose the following scenario. I log in the application and get a valid session token I browse the app and record several urls I want to scan. I set in session detection and application relogin in case I detect a logout. I choose them and start scanning with a threadcount of 3. Some time later, thread number 2 detects an out of session request. What happens now ? Do all threads stop until the Macro completes and a new session token is issued? Or each thread detects it is out of session since it could be using outdated tokens ? This is a race condition, if the macro manages to finish and update all tokens before another thread fires off its request then all is peachy, if not then we may end up in a loop where each thread is using a previously recorded token but is invalid since a semi concurrent request from a different thread updated it. Cheers, Zach

PortSwigger Agent | Last updated: Oct 02, 2015 08:08AM UTC

You are right that this can lead to problems re-establishing a session. We have a pending feature request to stall all applicable threads while a session is re-established. In the meantime, you might need to reduce the thread count or choose the option to validate every X requests.

PortSwigger Agent | Last updated: Feb 19, 2016 09:39AM UTC

It's not currently implemented. But we are activately working on a new approach to session handling that will deal with this situation correctly without any need to change or set configuration.

Burp User | Last updated: Feb 14, 2017 04:14PM UTC

Hi there, Following up on that from 1,5 years ago, have you implemented that feature in Burp or should I just go with the reduced thread count again ? Cheers, Zach

Burp User | Last updated: Feb 15, 2017 06:45AM UTC

Thanks a lot for the quick response. I am opting for the reduced thread count ( = 1 ) everytime I get in this situation but I am a bit pushed for time on the current engagement so I am exploring the validate every X requests option, the application very rarely - if at all - invalidates my session anyway. So let's say I have: Check valid session every 10 requests and Thread count = 3 Is the 10 requests a global counter or thread specific one? So - if it is global, if thread specific then all will have 10 - when the 10 requests are reached: T1 will have executed 4 requests T2 will have 2 and T3 will have 4 What happens in this case ? (a) All threads pause for the session valid check to happen or (b) the first thread that completes and is the 10th checks the session validity and the other happily continue and will update their cookies and parameters when the Macro for session recovery completes ? Alternatively, since I do not mind writing a bit of code myself, is there an API for putting the scanner on pause ? I checked and apart from cancel I could not find any other option. Cheers, Zach

PortSwigger Agent | Last updated: Feb 15, 2017 09:16AM UTC

The counter for the trigger to validate session is specific to the session handling action, and is not tied to any particular thread. In the situation you describe, if the trigger to validate session is met (in a given thread) then that thread will perform the check and the recovery action. Other threads will continue regardless.

Burp User | Last updated: Jan 22, 2018 02:43PM UTC

Has there been any change on how this works? I'm currently still reducing the thread count to 1 to play it safe.

PortSwigger Agent | Last updated: Jan 22, 2018 02:49PM UTC

Hi Michael, Thanks for your message. At present, no, there hasn't been any change on this. You may have noticed that the 1.7.31 release notes mention changing "Number of threads" to "Number of concurrent requests". That is one step towards a future model that will better handle this scenario.

Burp User | Last updated: Jun 28, 2019 06:21AM UTC

Was this fixed ?

Liam, PortSwigger Agent | Last updated: Jun 28, 2019 07:42AM UTC

Amit, could you specify the exact issue you're encountering? Which version of Burp are you using?

Burp User | Last updated: Jun 28, 2019 09:42AM UTC

The one specified by Zach above about session timeouts and the inability to maintain the session across threads. using 1.737 Prof edition.

Liam, PortSwigger Agent | Last updated: Jul 01, 2019 03:03PM UTC