Announcing HTTPXUI v1.0

Hello, httpxui #

I generally prefer the command line, but I encountered hurdles and limitations with my nearly exclusive command line approach to HTTP recon. These issues became particularly problematic when scaling up the number of active programs I was testing on. There were a handful of opportunities for improvement:

• When parsing httpx results, I’d pipe output to grep with wild patterns to filter the data and find what I was looking for
• Managing hundreds of text files from httpx (among other tool output) spread out across multiple directories and different machines
• Screenshotting was handled by separate tooling and disconnected from httpx data
• Screenshots included perception hashes (from gowitness and httpx), but these were not actionable
• I didn’t have a good system to keep notes on progress through recon results

Anyone who does bug bounty surely knows that speed and time is of the essence. With these challenges in mind, I created HTTPXUI as a solution to optimize HTTP recon!

HTTPXUI is designed as an HTTP flyover recon tool utilizing the awesome httpx library by ProjectDiscovery. It intends to optimize flyovers by always performing (nearly all) HTTP probes and screenshotting while persisting the results locally for organization, tracking, searching, and future reference of reconnaissance activity.

Features #

Run #

Run is where a new Session is kicked off, or in other words, how to start a new instance of httpx. Here, you’ll configure your targets (IP addresses, domain names), paths, ports, HTTP methods, threads, POST body data, and other parameters. Once a Run is started, it is then considered a Session, and the Session status is tracked via the bottom status bar or in the Sessions Overview screen.

Sessions #

Sessions are where all the current and past Run data can be viewed and you can drill down to specific endpoints. The first screen is Sessions Overview, displaying both previous and currently running sessions.

After you click the View button for a specific Session, the Session Details screen displays. This screen contains two sub-views: a screenshot grid view and a table view. The screenshot grid view includes a thumbnail image of the screenshot for all endpoints that returned data during the Session.

Each endpoint in the grid view has a button that will allow you to temporarily hide other endpoints that have a nearly identical screenshot image. This allows for quickly filtering out endpoints and identifying the interesting.

The table view displays all response data for each endpoint in a searchable tabular format. You can modify which columns are visible in the table and sort the data by clicking on the column headers.

Both views allow for searching based on various data of an endpoint. For example, search for a particular technology such as php, and the results will update to only display responses where that technology is present. Search supports the following data:

• URL
• Status
• Response Title
• HTTP Request Method
• HTTP Response Code
• Webserver
• Response Time (milliseconds)
• Content Type
• Content Length
• Words
• Lines
• Technology in use

Endpoint Details #

Endpoint Details will show IP / ASN information, TLS and certificate info, technology stack, and other details. On this screen, you can also set a status and store notes on the endpoint to keep track of your recon activity.

Settings #

Configure an HTTP proxy, custom HTTP headers, and custom DNS resolvers.

Privacy #

All data is persisted locally to your system in a SQLite database file. Upon running the application for the first time, a SQLite database will be created in one of the following locations depending on your operating system:

Architecture #

The project is built on the following technologies:

• Wails
• Go
• Pocketbase
• Svelte / SvelteKit

The desktop application is built on Wails. Wails allows for building cross-platform applications using web technologies that can interface with a Go runtime. This was a natural fit because the httpx library is written in Go. It also allows for being able to deploy to web with minor friction.

Pocketbase serves as the interface to the data store (a SQLite database file) via a REST-ish web API. It enables data privacy and portability by storing the data locally in SQLite.

I audited a few frontend frameworks (React, Vue, Angular) and chose Svelte / SvelteKit because it’s fast, small, and is an absolute pleasure to work in.

References #

• https://github.com/mattzajork/httpxui