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

Increase single-thread scanner speed

Antonio | Last updated: Mar 05, 2015 08:45PM UTC

Not sure if this is a bug or the standard behavior, so posting here first. I tried this with burpsuite_pro_v1.6.11.jar and burpsuite_pro_v1.6.02.jar with the default initial config. The application was hosted locally with apache. Same results. When I setup the scanner to do several items at the same time I see all the configured threads running simultaneously. Some of them go really fast, at multiple requests per second, but when there is only one thread active because it's the last one or because there is only one item to scan, the speed is reduced to approximately one per second. Is there a way to speed up single-threaded scans for one item? I don't think it's related to the application, as I can see fast single-thread speeds under some circumstances, as described above. Let me know if I can provide any further details.

PortSwigger Agent | Last updated: Mar 09, 2015 12:14PM UTC

We're not able to reproduce any difference in timing of Burp Scanner's requests based on the thread count, and we think the differences you observed are probably down to differences in the application's response times for different requests. Since each scan item operates on the same base request, and is handled by a single thread, it is likely that different items will proceed at different speeds, because the application process some requests faster than others.

Burp User | Last updated: Mar 09, 2015 05:37PM UTC

This is a simple LAMP-stack test application hosted locally. I can get a high number of GETs and POSTs per second with cURL. I've used the Logger++ extension to grab the request Burp Scanner was making at aprox. 1 request/s. I can then manually repeat it with cURL at faster speeds. Is there any specific test you can think of to verify that the speed limitation is not caused by Burp? This might be an environment issue...

PortSwigger Agent | Last updated: Mar 10, 2015 09:50AM UTC

Can you try adding the header: Connection: close to the base request you are scanning, and see if that makes things go faster?

Burp User | Last updated: Mar 16, 2015 11:14PM UTC

That was it! First I made the change in the proxy, adding a "Match and Replace" rule to set all requests with "Connection: close", and the browser requests increased in speed from 1/s to a few ms. Then I scanned one of the slow requests sending it from Repeater with "Connection: close", and it was instant. I then disabled KeepAlive in the apache configuration, and that made ALL the requests fly. You nailed it! I'm now just trying to figure out how I can make the Scanner set this for me when I start scans with the Scanning Wizard. Do you know if this is possible? Thank you, you guys are awesome.

PortSwigger Agent | Last updated: Mar 17, 2015 09:19AM UTC

Glad you got things working. This issue comes up occasionally with some configurations of target servers. We plan to add some new options to Burp shortly, to set the Connection: close header. In the meantime, if you use the Proxy match/replace rule that you have, and also configure the Connection: close header in the Spider headers options, then the requests that are sent to the Scanner will already have the required header.

PortSwigger Agent | Last updated: Jul 26, 2015 08:39AM UTC