Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

The value of toolFlag transforms from TOOL_EXTENDER to TOOL_SCANNER

Yuji | Last updated: Feb 22, 2018 08:47AM UTC

Since version 1.7.32 of BurpSuite, when a Burp Extender sends HTTP requests using IBurpExtenderCallbacks#makeHttpRequest while active scanning, IHttpListener#processHttpMessage sets IBurpExtenderCallbacks#TOOL_SCANNER to the value of toolFlag. As you already know, versions earlier than 1.7.31, it is IBurpExtenderCallbacks#TOOL_EXTENDER. Thanks, Yuji

PortSwigger Agent | Last updated: Feb 22, 2018 12:28PM UTC

Hi Yuji, Thanks for reporting this. We're going to investigate further and look at resolving the issue.

PortSwigger Agent | Last updated: Mar 02, 2018 02:05PM UTC

Hi Yuji, We've now discussed this issue internally. The change was introduced when we fixed another bug - that extension scan checks did not obey the concurrent request limit. Whether such checks should be tagged as "scanner" or "extender" can be debated, but we've decided that scanner is an appropriate designation and we're going to maintain this behavior. Thanks again for reporting the change in behavior.

Burp User | Last updated: Mar 06, 2018 02:00AM UTC

Thank you for your reply. I agree that tagging “scanner” is appropriate. However, this behavior was useful for classifying HTTP messages. We are using value of toolFlag for statistics and log analysis. Is there a way to identify requests generated by "extender" since v1.7.32?

PortSwigger Agent | Last updated: Mar 06, 2018 08:43AM UTC

Hi Yuji, You can still identify all extension requests that are made outside of doActiveScan as the tool flag remains the same. There's no easy way to identify extension check from built-in checks. Is this important for your statistics? Are you doing something like "bandwidth of built-in checks vs custom checks" ? As a hack you could add custom headers to your requests to identify them. Sorry this change makes things more difficult for you.

Burp User | Last updated: Mar 12, 2018 03:04AM UTC

Our team sends information such as HTTP messages to the log server and displays various statistical information on the dashboard. This includes statistics that you said - bandwidth of built-in checks vs custom checks. Unfortunately, it is important information for us: - behavior analysis of excellent testers. - how was the vulnerability detection payload generated. We use unspecified extensions, so your hack can not be applied. I'm very sorry, but could you please consider the "extender" tagging again? It is easy to integrate "extender" into "scanner" by Extender's logic, but not vice versa. It may be inappropriate, but I believe it is useful.

PortSwigger Agent | Last updated: Mar 12, 2018 08:26AM UTC

Hi Yuji, Thanks for explaining more about your use case. We have discussed this internally and agree with your recommendation. In fact, we have already updated our master source tree to revert Burp to the previous behavior. This will be available in the next release. Please let us know if you need any further assistance.

Burp User | Last updated: Mar 13, 2018 06:45AM UTC

I am grateful for your support. I am looking forward to the next release. Thanks!

PortSwigger Agent | Last updated: Mar 13, 2018 09:01AM UTC

Hi Yuji Just to let you know that this issue should be fixed in today's release (1.7.33). Thanks for your feedback and please let us know if you run into any other problems.

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