Support Center

Burp Community

See what our users are saying about Burp Suite:

How do I?

New Post View All

Feature Requests

New Post View All

Burp Extensions

New Post View All

Bug Reports

New Post View All
Documentation

Burp Suite Documentation

Take a look at our Documentation section for full details about every Burp Suite tool, function and configuration option.

Full Documentation Contents Burp Projects
Suite Functions Burp Tools
Options Using Burp Suite
Extensibility

Burp Extender

Burp Extender lets you extend the functionality of Burp Suite in numerous ways.

Extensions can be written in Java, Python or Ruby.

API documentation Writing your first Burp Suite extension
Sample extensions View community discussions about Extensibility
Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

Burp session handling in multiple scanner threads

Zach Pigadas 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


Dafydd Stuttard Oct 02, 2015 08:09AM UTC Support Center agent

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.


Zach Pigadas 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

Dafydd Stuttard Feb 14, 2017 04:28PM UTC Support Center agent

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.


Zach Pigadas 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

Dafydd Stuttard Feb 15, 2017 09:18AM UTC Support Center agent

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.


Michael 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.

Paul Johnston Jan 22, 2018 02:51PM UTC Support Center agent

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.


Post Your public answer

Your name
Your email address
Answer