Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

makeHttpRequest is very slow

CD | Last updated: Sep 15, 2015 02:03PM UTC

Hi all, I'm writing an extension that aims at sending many requests from multiple sessions of different users. Currently, I'm using callbacks.makeHttpRequest(...) to send requests but that method takes a very long time to finish. My server is local and pretty fast, so communication does't take that much of time. Is there any faster way to replace that method? I'm thinking about using the Intruder or Scanner Interface but not so sure if they can help.

PortSwigger Agent | Last updated: Sep 15, 2015 02:13PM UTC

Some suggestions: Is your request definitely well-formatted? Does it use CRLF for all line endings, and include a blank line after the headers (i.e. CRLFCRLF)? Does it include an accurate Content-Length header for messages with a body? Have you added the "Connection: close" header, for good measure? The most common cause of this problem is requests that are not standards-compliant, and cause web servers to wait for more data, until a timeout occurs.

Burp User | Last updated: Sep 15, 2015 02:57PM UTC

What I did is: 1) Use callbacks.getSiteMap(...) to get requests 2) Update the requests cookies with callbacks.getHelpers().updateParameter() 3) Send the requests From the document of IExtensionHelpers I believe that the issues you mentioned should be handled. Is there any way to call burpsuite through the callbacks object to send requests in parallel?

PortSwigger Agent | Last updated: Sep 15, 2015 03:32PM UTC

It sounds like the requests you are sending ought to be well-formed. It might be worth absolutely double-checking this, in case something weird is going on. You could also consider adding the "Connection: close" header, which might help. You can certainly send requests in parallel, by spinning up your own threads and issuing requests in each thread.

PortSwigger Agent | Last updated: Sep 15, 2015 03:34PM UTC

Thanks for the further details. We're not able to reproduce any deadlock/race condition with concurrent updates to the site map. We have a lot of automated tests around multi-threaded use of the site map. Also, I manually created an extension that starts 100 threads, all running in a loop adding new items to the site map with random filenames. Burp appears to run fine and the site map is fully usable. If you're still seeing this issue, and are able to share your code that reproduces it, we'll be able to investigate further.

Burp User | Last updated: Sep 16, 2015 10:22AM UTC

Thank you for your suggestions. I'll double check the requests and add the header. Regarding parallel executions, in fact, I have tried to have multiple threads but then I have a race-condition problem (I guess) with callbacks.addToSiteMap(...), each time a request is done I add it to the sitemap. However, calling that method from multiple threads makes the whole BurpSuite frozen.

Burp User | Last updated: Oct 14, 2015 07:51AM UTC

Thanks for the test and suggestion. Just to summarise what we discuss: 1) Slow makeHttpRequest(), Solution: adding the header: "Connection: close" helps speeding alot 2) Calling callbacks.addToSiteMap(...) from multiple threads is not a problem. (In fact, we had a race condition in our code, it is not due to addToSiteMap())

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