Skip to content

Latest commit

 

History

History
102 lines (72 loc) · 3.78 KB

README.md

File metadata and controls

102 lines (72 loc) · 3.78 KB
Raw
BugHog logo
pytest_job Docker Image Version (tag) Docker Image Size

BugHog is a powerful framework designed specifically to address the challenging task of pinpointing the exact code revisions in which a particular browser bug was introduced or fixed.

This framework has been developed as part of the "A Bug's Life: Analyzing the Lifecycle and Mitigation Process of Content Security Policy Bugs" paper to identify Content Security Policy bug lifecycles, published at USENIX Security '23.

USENIX Association artifact evaluated badge USENIX Association artifact functional badge USENIX Association artifact reproduced badge

Getting started 🚀

BugHog is compatible with UNIX systems running Docker, including WSL on Windows. You will need at least 5 GB of disk space.

Follow these steps to get started:

# Clone this repository
git clone https://github.com/DistriNet/BugHog
cd BugHog

# Pull our pre-built Docker images
./scripts/pull.sh

# Start the pulled images
./scripts/start.sh

Open your web browser and navigate to http://localhost:80 to access the graphical user interface. If BugHog is started on a remote server, substitute 'localhost' with the appropriate IP address.

Note

Depending on your Docker configuration, you might have to use sudo ./scripts/[..].

BugHog in default configuration will spin up its own MongoDB container, which persists data in the /database folder. Configuring BugHog to use your own MongoDB and other options are explained here.

Tip

Our 30-minute tutorial will guide you on how to use BugHog to trace a real bug's lifecycle!

To stop BugHog, simply run this in the project root:

./scripts/stop.sh

Development 🛠️

Use the following commands to build the Docker images yourself, for instance after you made changes to the source code:

# Build BugHog images
./scripts/build.sh

# Run the freshly built images
./scripts/start.sh

Note

For reference, building takes about 4 minutes on a machine with 8 CPU cores and 8 GB of RAM.

Debugging

The most convenient debugging approach is to launch an interactive Node environment. The UI can be visited at http://localhost:5173.

./scripts/node_dev.sh

For debugging the core application, consider using the VS Code dev container. You can utilize the configuration in .devcontainer for this.

Support and contact ☎️

More information on how to use BugHog can be found here.

For questions, remarks or collaboration, you can reach out to Gertjan Franken.