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

Time discrepancy in Intruder vs Logger

Joshua | Last updated: Oct 27, 2022 02:27PM UTC

I've been using intruder to test some timeouts. I put a request in intruder, set null payloads, set the resource pool to send a single request every 5 minutes so I can see when things quit working.. What I've noticed is that Intruder seems to be queuing up the request and including the timestamp of when the request enters the queue. The request doesn't actually go out though due to the resource pool limitations. In Logger, the request can be seen at the actual time it was sent to the server. It's also easy to see that this is occurring since the request is shown in the results with the time it was added but the response is delayed until the resource pool limitations will allow it to be sent. Reproduction steps follow, slightly different than then above scenario to prove the discrepancy by adding an identifier to the request headers. To Reproduce: 1. Send a request to intruder and clear all insertion points. 2. Add a header called "Count" to the request and set an insertion point for its value. 3. Set the payload type to Numbers, from 1 to 10, step 1. 4. Create a new resource pool with 1 maximum concurrent request, fixed delay between requests of 10000 milliseconds. 5. Start attack, allow a few requests to run. 6. In the results screen, select Columns > Time Of Day to add the time to the results. 7. In the main burp window select the Logger tab. 8. Locate the same request in both the logger tab and the intruder results tab. They can be matched by the value of the Count header in the request. 9. Observe the time reported by Intruder results in 10 seconds earlier than the time reported by logger. Expected behavior is that the time of day shown in the results of the intruder column accurately reflect when the request was sent to the server.

Liam, PortSwigger Agent | Last updated: Oct 28, 2022 10:36AM UTC

Thanks for your message, Joshua. We'll investigate and get back to you.

Liam, PortSwigger Agent | Last updated: Oct 31, 2022 06:29AM UTC

Hi Joshua. We've reproduced the behavior you are encountering. We'll check in with the product team and get back to you. Thanks for your patience.

Liam, PortSwigger Agent | Last updated: Oct 31, 2022 04:59PM UTC

We've created a bug ticket to get this fixed. Thanks again for your feedback.

exploresecurity | Last updated: Nov 09, 2022 12:31PM UTC