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

Saving Repeater data to project files

Rennie | Last updated: Mar 28, 2022 09:35PM UTC

One of our largest customers wants our consultants to submit Burp project files logging all project-related traffic to them after each pentest so that they can audit us. This is currently difficult as while Burp’s project files store proxy history, they do not store history from Repeater or many other tools. We currently have the following options: 1. Use two Burp instances, with instance B set as the upstream proxy of instance A, then do all testing in instance A and give the customer project files from instance B. This is awkward to set up and use; if someone accidentally tests using instance B, then that will not be logged properly. 2. Burp has logging for Repeater and other tools, which can be enabled using Project Options > Misc > Logging. However, these logs go to separate text files and our customer is insisting that everything be in the project file. Further, this needs to be individually enabled for every project; there’s no option to automatically log to a file whose name is derived from the project name. 3. Use an extension such as Logger++. These also log to separate files. I'm not aware of any way for extensions to save data into project files. In order to help us with this problem, would you be willing to implement an option to log Repeater and other tools into project files then make those logs available through Logger when project files are opened? Another useful change would be to add a method to the extension API to allow extensions to save data into project files.

Michelle, PortSwigger Agent | Last updated: Mar 29, 2022 01:00PM UTC

Thanks for your message. I can see one of your colleagues has also emailed us on this subject and has already had a reply. We have registered your interest in a feature to retain the Logger data in the project file. If either you or your colleague has further questions, please let us know via the email trail.

Rennie | Last updated: Mar 30, 2022 10:15PM UTC

I've been investigating options for importing Burp text logs into proxy history or into an extension that allows them to be searched, and discovered that they're not unambiguously parsable. The text logs use "=====...===" to mark the end of records, but make no allowance for requests or responses that contain that string. So it's not possible to distinguish based on the log between two request-response pairs and a single request-response pair, where the request contained a logged response followed by a logged request. If nothing else, could you at least fix that and make sure that all requests and responses (whether text or binary and regardless of their content) can be unambiguously parsed from your logs?

Hannah, PortSwigger Agent | Last updated: Mar 31, 2022 03:15PM UTC

Hi Do you have some examples of request-response pairs that you are finding difficult to parse? If needed, you can drop us an email at support@portswigger.net. From what I can tell, the "===" strings are always consistent in length, requests always start with the time, URL and IP address of the request, and responses always have the "===" string followed by the response code from the server.

Rennie | Last updated: Apr 02, 2022 07:50PM UTC