When working on a project I want to keep all project data in one directory. I keep notes and logs to make reporting easier, and to be able to answer customer questions. Although it’s rare, sometimes it is necessary to go back through the logs to see what happened during the test. In that case the logs need to be complete, and contain only information from that project. To make this easier, I have partly automated a workflow I will explain below.
The goal of my workflow is to easily store project data in the project folder, and to prevent contamination with other projects or non-project related work. When I am hacking Acme’s API I want all requests to go through Burp, keep screenshots, notes, and browser history. When I switch to Wayne’s web app, I don’t want to have requests to Wayne end up in Acme’s Burp project, and vice versa. Projects need to be strictly separated, while making it easy to store information.
Using a virtual machine
I used to have a virtual machine running Kali Linux for hacking. By using a VM it is possible to make snapshots and revert to a clean state, making sure projects don’t contaminate each other. However, virtual machines have some drawbacks:
- Copy-pasting between the VM and the host often breaks.
- The snapshots take up considerable disk space.
- The VM is not integrated in the windowing system of the host. Getting the VM to work right on multiple screens is a challenge.
Using a VM is particularly useful since it segments all your files. If you add a static mapping to
/etc/hosts, it is gone as soon as you revert to a clean snapshot.
In practice, it sometimes still happens that project files end up in the “clean” VM snapshot. As with all systems like this, you have to remember to switch contexts.
Especially the problems with multiple screens led me to try another solution. At first I had one VM with a browser connected to another VM with Burp. However, this made little sense, especially when Burp started supporting projects in 2016.
I switched to running the browser, Burp, and some other tools directly on MacOS and discarded the virtual machines.
Burp projects work great at separating data from different projects. For the browser I used to clear all data (⌘⇧⌦) every time I switched projects, but later I created a new Firefox profile for each project.
Initializing a project
I created a shell script that initializes a new project. It creates a new directory with the given name, a new Firefox profile and a new Burp project. It creates these subdirectories in the project directory:
burpstores the Burp project and log.
codehas any available source code.
screenshotshas all screenshots for this project.
projecthas the project information such as the proposal.
binhas some project specific scripts, particularly to start the browser and Burp with the correct arguments.
And finally, it creates a file
notes.txt to contain all notes made during the project.
Symlink for current project
Each project has its own directory. There is a symlink named
current that points to the directory of the current project. This is automatically set by the project initialization script described above, and I can set it to any project when I change projects. This makes it easy to find the files for the current project, and I can configure tools to save files to this directory.
One use of the
current symlink is to save screenshots. Screenshots are saved to the
screenshots directory in the current project. So now I can take screenshots with ⌘⇧4 and they automatically end up in the correct directory of the current project. The following command changes the directory screenshots are saved to:
defaults write com.apple.screencapture location /Users/me/Projects/current/screenshots
The project initialization script creates a new Firefox profile specifically for the project. This facilitates project specific browser history, saved passwords, and saved form inputs.
After creating the project, the script copies a custom user.js into the profile folder. This configuration file makes Firefox use Burp as proxy and sets some other preferences.
Each project has its own script to start Burp, which specifies the project and configuration files to use. The configuration file in turn enables logging to
/burp/$project.log. The file
bin/burp that starts Burp for the current project looks like this:
~/bin/burp --project-file='$PWD/burp/$project.burp' --config-file='$PWD/burp/$project.conf.json' --unpause-spider-and-scanner
Currently, it is possible to start the browser of one project while running the Burp instance of another project. Requests then end up in the wrong Burp project. To avoid this, each project could use its own port number for the proxy. Firefox connects to Burp on this project specific port, making it impossible to connect Firefox to the wrong Burp project.
Another possible improvement would be to make it clearly visible to which project a Firefox instance belongs. It would be nice if the project name was visible in the title bar, but I have not yet found a way to do so.
Using several bash scripts I create a new Firefox profile and Burp project for each project. This keeps project information separate and complete.