Home

Awesome

NightBuild Known Vulnerabilities License: GPL v3 BAppStore Version

Log Requests to SQLite

This extension has a single objective:

Keep a trace of every HTTP request that has been sent via BURP.

Why?

When I perform an assessment of a web application, it is often spread on several days/weeks and during this assessment, I use the different tools proposed by BURP (Proxy, Repeater, Intruder, Spider, Scanner...) to send many HTTP request to the target application.

Since a few months, I have met a situation that happens more and more with the time: Some time after the closure of the assessment (mission is finished and report has been delivered), the client ask this kind of question:

Most of the time, I answer to the client in this way: "This is the IP used for the assessment (the IP is also in the report by the way), check the logs of your web server, web app server, WAF..." because it's up to the client to have the capacity to backtrack a stream from a specific IP address.

In the same time, I cannot give the BURP session file to the client because:

So, I have decided to write this extension in order to keep the information of any HTTP request sends in a SQLIte database that I can give to the client along the report and let him dig into the DB via SQL query to answer his questions and, in the same time, have a proof/history of all requests send to the target application...

Once loaded, the extension ask the user to choose the target database file (location and name) to use for the SQLite database or to continue using the current defined file in the previous session.

Regarding the file name to use, there no constraint applied on it but I recommend to use a file with the .db extension to facilitate the usage with a SQLite client for exploration operations.

After, the extension silently records every HTTP request send during the BURP session.

Extension Log

DB Content

Options

Scope

There is an option to restrict the logging to the requests that are included into the defined target scope (BURP tab Target > Scope):

Scope Option Menu

Images

There is an option to exclude the logging of the requests that target images (check is not case sensitive):

Image Option Menu

The list of supported file extensions is here.

Include the responses content

There is an option to log also the response content, in raw, associated to a request. By default, this option is disabled.

Logging of the responses Option Menu

Pause the logging

There is an option to pause the logging (re-click on the menu to resume the logging):

Pause Option Menu

When the logging is paused then when Burp is restarted, it keep in mind that the logging was previously paused and then reflect the state in the menu:

Pause Option Menu

Otherwise, when Burp is started and logging was not previously paused then the following options are proposed:

Pause Option Menu

Change the DB file

:warning: This option require that the logging was paused.

There is an option to change the DB file during a Burp working session:

ChangeDB Option Menu

Statistics

There is an option to obtain statistics about the information logged in the database:

Image Stats Menu 1

Image Stats Menu 2

Build the extension JAR file

Use the following command and the JAR file will be located in folder build/lib:

$ gradlew clean fatJar

Audit third party dependencies

The goal dependencyCheckAnalyze can be used to verify if one of the dependencies used contains CVE.

Use the command line option -PodcGradlePluginVersion=x.x.x to specify a specific version of the OWASP Dependency Check Grable plugin

$ gradlew -PodcGradlePluginVersion=3.2.1 dependencyCheckAnalyze

Night build

See the Actions section.

BApp Store

The extension is referenced here.

BApp Store update procedure

Procedure kindly provided by the PortSwigger support:

  1. BApp Author commits fixes/updates to the master repository.
  2. Once BApp Author is happy that updates need to be pushed to the BApp store, the Author creates a pull request so changes can be merged into the forked repository: righettod wants to merge xx commits into PortSwigger:master from righettod:master
  3. BApp Author notifies PortSwigger support that changes need to be merged, support staff reviews changes and then accepts pull request so the changes are merged.
  4. BApp is then compiled from the forked repository version and then pushed to the BApp store.

Change log

2.0.0

1.0.9

1.0.8

1.0.7

1.0.6

1.0.5

1.0.4

1.0.3

1.0.2

1.0.1

1.0.0

SQLite client

Cross-platform: https://github.com/sqlitebrowser/sqlitebrowser