Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Identify scanning threads using the Extender API

Kyle | Last updated: Jul 19, 2016 04:43PM UTC

A question was posted as to whether Burp can scan an application using different session information for each thread and the response that it is a feature that Burp does not have, however it is something that a custom extension could be written to handle sessions: https://support.portswigger.net/customer/portal/questions/9957995-how-to-run-multiple-session-while-scanning-application-through-burp- I am attempting to do such a thing, but I can't seem to find any way to determine which thread is executing each request/response. I would need to be able to identify each thread as "Thread A", "Thread B", "Thread C", etc, and link the series of requests and responses to an individual thread and thereby assign a consistent session ID for each thread. For example: Thread A would always use session ID "ABCD" Thread B would always use session ID "EFGH" Thread C would always use session ID "IJKL" ...and so on for each of the 10 scanning threads. Using the java call "Thread.currentThread().getName()" each time a request or response is processed always results in a unique thread name instead of a set of 10 unique threads. The value I get looks something like "pool-5-thread-####" where the last four characters are numeric characters that keep incrementing - I never see the same thread name used for more than a single request/response. How can I identify each thread executing? I may misunderstand how the multi-threaded nature of Burp operates. Is it possible that a new thread is spun off for each request/response? If so, can I manage the creation of these threads using the API? Any insight/help is appreciated.

PortSwigger Agent | Last updated: Jul 20, 2016 08:14AM UTC

Thanks for fhis feedback. It looks like it isn't trivial to implement per-thread session tokens via an extension, by simply tying a token to an individual thread. But you could still implement your own "pool" of tokens that you use in outgoing requests. When a token has been used in a request, you could avoid using the same token again until the corresponding response has been received. This should achieve the same results as a per-thread token, in terms of avoiding concurrent usage of the same token in multiple requests.

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