Burp session handling in multiple scanner threads
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.
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.
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 ?
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.
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.
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.
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.
Amit, could you specify the exact issue you’re encountering?
Which version of Burp are you using?
Amit, could you try updating to Burp Suite 2.1. Let us know if the problem persists.