A Kotlin Burp Suite extension that exposes the full Montoya API as a local, Swagger-documented REST service so authorized testers and AI agents can script scans, requests and analysis programmatically.
| Tool | forefy/reburp — Burp Suite extension exposing the full Montoya API as a local REST API with OpenAPI/Swagger |
| Category | Burp Suite extension / test automation bridge (Kotlin, MIT) |
| Primary Use | Scripting authorized web assessments: driving Scanner, Intruder, proxy history search, WebSocket testing and utilities over curl or an AI agent |
| Safe Use | For penetration testers working under signed authorization on in-scope targets, lab environments, and defensive research into tooling automation |
| Telemetry Note | Every REST call is logged in the reburp tab and persisted via /api/log/; shell execution is audited in the extension output tab. The service itself binds 127.0.0.1:9090 only, so defenders watching a workstation see local loopback traffic to port 9090 |
reburp is a Burp Suite extension from forefy that answers a long-standing frustration for professional testers: Burp is extraordinarily capable, but its own extension API surface — the Montoya API — is only directly reachable from Java code running inside Burp. reburp loads as a standard Java extension and re-exposes that entire API as an HTTP REST service on http://127.0.0.1:9090, complete with an OpenAPI spec at /openapi.json and a Swagger UI at /docs. The tagline in the README is blunt — Burp's native API/MCP offering is limited, and reburp is positioned as the full-fidelity alternative, explicitly optimized for AI agents.
The repository metadata reinforces that positioning: 104 stars, Kotlin as the implementation language, an MIT license, and topics including agentic-ai, burp-extension, montoya-api, openapi and pentesting. The project ships with a companion agent skill, burp-interaction, bundled under .claude/skills/, which lets an AI assistant drive Burp directly through the REST surface. The core idea is that anything you would normally click — reading proxy history, sending a request, editing scope, launching a scan, decoding a token — becomes a JSON call that either an agent or a plain curl line can make.
What the extension unlocks is impressively broad. The README enumerates Burp features your agent can now drive: the Scanner (start active audits or crawls, stop tasks, pull reports), Intruder-style fuzzing plus a Turbo Intruder-like high-throughput request engine with queue, pause, resume and cancel, full Target site map iteration and search, WebSocket connections with text and binary frames, engagement tools such as CSRF PoC generation, content discovery and find-references, and an access-control testing workflow that replays a request with and without its token and diffs the responses — an Autorize-style pattern useful for BOLA/BFLA checks. It also covers BChecks import and Bambda filter chains, so custom scan rules can be managed programmatically.
The endpoint map is organized into more than two dozen prefixed groups. /api/proxy/ covers history, search, annotation, intercept toggling and WebSocket history; /api/sitemap/ and /api/scope/ handle the target tree and scope rules; /api/http/ sends HTTP/1.1 and HTTP/2 with auth-token injection, parsing, diffing, parameter inspection, reflection detection and insertion points. /api/scanner/ and /api/collaborator/ expose Pro-only features (returning 403 with an explanatory message on Community edition), while /api/repeater/ and /api/intruder/ push requests into the interactive tools. There is also a large /api/utils/ surface: URL and base64 encoding, hashing, JWT decode, JSON pointer editing, byte-buffer manipulation, radix conversion, and a ranking utility that orders proxy history by how anomalous each exchange looks — a genuinely interesting signal for triage in an authorized assessment.
Architecturally, the README reveals a disciplined project. The Montoya API is declared compileOnly, meaning it is not bundled — Burp provides it at runtime, which is the correct pattern for extensions. The OpenAPI spec is assembled from OpenApiSpec.kt plus fragment files under docs/, and contributors adding a route group are expected to ship matching *Paths() and *Schemas() fragments so documentation stays complete. Most notably, the "full Montoya API" claim is verified mechanically: tools/api_coverage.py runs in CI on every push and fails the build if any mappable method is left unexposed, with tools/smoke_test.py exercising behavior against a loaded extension. That is a stronger guarantee than most extension projects offer.
Installation is conventional for the ecosystem: grab a reburp-*.jar from the GitHub Releases page, or build from source with git clone https://github.com/forefy/reburp.git followed by ./gradlew shadowJar (Java 17+). A practical detail from the README is worth internalizing: load the unversioned reburp.jar rather than the versioned copy, because Burp reloads an extension from its original path, and the versioned filename changes on each release — using the stable name means upgrades actually take effect instead of leaving you silently on the previous build. Once loaded through Extensions → Installed → Add, the extension starts automatically on port 9090 and a dedicated reburp tab appears showing every REST call with method, status, timing, path and notes.
Versioning is pinned to Burp releases: every 1.1.x build requires Burp Suite 2026.7 as a minimum Montoya baseline, while the 1.0.x line targets 2025.12. If you run an older Burp, the compatibility table directs you to the matching historical jar. This tight coupling is a natural consequence of wrapping the full Montoya API — surface area grows with every Burp release, and the CI coverage check presumably forces rebuilds whenever PortSwigger adds mappable methods. The hardcoded port is the one inflexible bit; the README notes you must edit port in BurpRestApiExtension.kt and rebuild to change it.
The security section deserves careful attention from any operator deploying this. The REST server binds 127.0.0.1 only, but the port is unauthenticated and responds to any origin — meaning any web page open in your browser can attempt to reach localhost:9090 and drive your Burp. The README is explicit: treat the port as trusted-local-only and never expose it beyond loopback. Because of exactly this risk, OS command execution via /api/utils/shell/ is disabled by default and returns 403 unless REBURP_ENABLE_SHELL=1 is present in Burp's own process environment, at which point any origin reaching the port effectively gains code execution on the host. Every shell invocation is logged to the extension output tab, and GET /api/utils/shell/status lets you check the state safely.
Observability runs through the whole design. Each REST call is logged in the extension tab, with the selected call showing both the API request and response plus the actual request and response reburp transmitted to the target on your behalf — a transparency feature that matters when an agent, not a human, is issuing traffic. The persisted call log is itself queryable through /api/log/, and /api/logging/ writes into Burp's event log. For defenders, this gives a complete audit trail of what the automation actually did during an engagement, which is exactly what you want for reportable, authorized work.
Where does reburp fit in a professional workflow? It is best understood as an automation substrate rather than a scanner or exploit tool itself. Assessment teams building custom pipelines — feeding proxy history into analysis tooling, orchestrating authenticated crawls, diffing authorization behavior across roles, or wiring an LLM assistant into live testing with human oversight — get a uniform, documented, JSON-speaking interface to Burp's full capability set. The /api/engagement/ group and the /api/http/engine/ high-throughput engine with resource pools, throttling and retries (Burp 2026.x) mean even heavy authorized load testing patterns can be scripted with backpressure controls baked in.
Caveats for adopters are few but real: the loopback-only unauthenticated binding means browser-based cross-origin reachability is a live consideration during assessments where you browse attacker-influenced content; Pro-only endpoints degrade to 403 on Community; and the hard Burp version coupling means you should check the compatibility table before upgrading either side. Overall, reburp is one of the more thoughtfully engineered Burp extensions in the automation space — mechanically verified API coverage, an honest threat model documented in the README, and a clean path from click-driven testing to scripted, agent-assisted assessment under proper authorization.
forefy/reburp.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.