diff options
Diffstat (limited to 'PLAN.md')
| -rw-r--r-- | PLAN.md | 93 |
1 files changed, 93 insertions, 0 deletions
@@ -775,3 +775,96 @@ real Actions run to execute) against a real `make release` output - confirmed all 6 platform archives (2 macOS, 2 Linux, 1 Windows, 1 FreeBSD) build with correct internal structure, `zip` selected only for the Windows target, and `SHA256SUMS` covers all of them. + +## Plugin ecosystem + +The goal, per direct request: parity with the extensions/Pro features +working Burp users actually rely on - "the best plugins, especially the +paid ones" - not a single proof-of-concept. Researched the current +BApp Store landscape and Burp Pro's paid-tier feature set to ground +this rather than guess from memory; see the grouping below. + +### Architecture decision + +Considered two shapes: an embedded scripting language (Lua/Starlark +interpreter in mitmuxd, plugins as hooked scripts) versus external +processes speaking mitmux's own existing IPC protocol. Chose the +latter, explicitly: any language (a plugin doing crypto work might +want Python's `jwcrypto`, a fast passive scanner might want Go - no +reason to lock authors into one embedded language), no new interpreter +dependency or sandboxing model to design and maintain, and it mirrors +the daemon/TUI split already in place - a plugin is architecturally +just another TUI, watching and acting on the same socket. Documented +in full, protocol-first (any-language authors need a real spec, not Go +doc comments), in `PLUGINS.md`. + +### Phase 1: tag + stored data (shipped) + +The prerequisite for everything else: a `tag_entry` IPC request lets +any connected process mark a history entry with a short string tag and +an opaque, plugin-defined JSON data blob, stored in a new `entry_tags` +table. Deliberately NOT a live round-trip to a still-connected plugin +process for every view - a plugin does its analysis once, tags the +entry with whatever data a human will want to see later, and the panel +just reads what got stored. Simpler, and works even if the plugin has +long since exited by the time someone reviews the entry. + +This one capability, paired with the IPC surface that already existed +(`subscribe` for live traffic, `repeat` for sending probe requests, +`list`/`search`/`get` for reading history), is enough for an entire +tier of plugins with no further protocol work: Autorize (replay with a +different session token, diff, tag likely IDORs), Param Miner (probe +for hidden parameters/cache poisoning, tag hits), Backslash Powered +Scanner (payload-variant diffing for injection), Retire.js (passive +scan of response bodies against a known-vulnerable-JS-library list). +Logger++/Content-Type-Converter/JSON-Beautifier-class extensions were +considered and skipped - mitmux's own History+FTS5 search and Decoder +tool already outperform what they'd add. + +TUI integration: `Summary.Tags` (a comma-joined, correlated-subquery +aggregate - cheap enough per row that List/Search need no N+1 query) +renders as a new `Tags` column in the history table, sortable via +`o`/`O` like any other column, and matchable via a new `tag:name` +search filter (same `extractStructured` mechanism as `status:`/ +`source:`/`flagged:`). `EntryDetail.Tags` carries the full record +(plugin name + tag + data) for the entry currently open; `T` from +detail view opens a list of them (mirroring the WebSocket-messages +view's own table-then-detail-viewport pattern, added earlier), `enter` +on one shows its data - JSON-colorized via the same `jsoncolor.go` +already built for pretty-printed response bodies if it parses as JSON, +plain sanitized text otherwise. Tag data goes through the same +sanitizeBlock treatment as any other externally-sourced text reaching +the real terminal - a plugin can echo back attacker-influenced content +(e.g. a header value it parsed), so it's not implicitly trusted just +because it came from a plugin rather than raw traffic. + +### What's grouped where + +- **Cheap IPC-plugin wins** (Phase 1 covers these fully): Autorize, + Param Miner, Backslash Powered Scanner, Retire.js. +- **Needs a second protocol addition** - a live round-trip to a + specific still-connected plugin, for an interactive action rather + than a passive tag (JWT Editor's "re-sign this with a different key, + right now" button; SAML Raider's equivalent XML re-signing): JWT + Editor, SAML Raider. Not yet built - Phase 1's tag+data display + already covers the *decode and view* half of what these do; only the + *live re-sign* half needs the new capability. +- **Needs real UI beyond a data panel**: InQL/GraphQL Raider (a schema + browser/query explorer, not just a decode view) - bigger lift, later. +- **Deserves its own separate project, not a plugin**: Burp Scanner and + Burp Bounty's custom active-check DSL (active vulnerability scanning + is a whole subsystem - check-diffing engines, hundreds of injection + variants - and already explicitly out of scope per this README's own + "a manual-testing tool, not a scanner"); Collaborator/OAST (needs + real internet-reachable DNS/HTTP infrastructure running somewhere, + not something an in-process plugin can be); a crawler (spidering is + its own substantial subsystem). Turbo Intruder's actual value is raw + throughput - mitmux's own Intruder already covers all four of Burp's + attack modes, so if extreme concurrency is ever wanted, that's a + core-engine change to how requests get dispatched, not something a + plugin protocol should be shaped around. + +Next: Phase 1's plugins themselves (Autorize- and Param-Miner- +equivalents first, since they validate the simple subscribe-act-tag +path before anything gets built on top of it), then the live-RPC +protocol addition for JWT Editor/SAML Raider. |