From c2443f27ef5a844f045c038c7689d217d1dbf0c4 Mon Sep 17 00:00:00 2001 From: srdusr <99972264+srdusr@users.noreply.github.com> Date: Mon, 23 Sep 2024 21:33:00 +0200 Subject: Match-and-replace: header rewrite rules Implements build-order step 6, scoped to headers only for this pass - see PLAN.md for why bodies are a separate problem (request-body capture currently depends on streaming straight through, which a body-rewriting rule would have to interrupt; deciding what "exact" means for a rule-modified request needs its own pass, not a rushed add-on to this one). internal/rules: Rule type and ApplyHeaders, which serializes a Header map to a raw "Name: value\r\n" block, runs enabled rules' match/replace over that text, and reparses it - operating on text rather than per-value substitution is what lets a rule add or remove a header, not just rewrite one, matching how Burp's header match/replace works. Invalid rule output (bad regex, unparseable result) leaves the header map untouched rather than corrupting the request. internal/store: rules table + CRUD. internal/proxy: forward() fetches enabled rules for each scope and applies them to outReq.Header / resp.Header, positioned so the existing capture/history pipeline is untouched - request_raw keeps showing what the client actually sent and response_raw what the origin actually sent, while the wire itself reflects the rules. Deliberate split: match-and-replace transforms traffic, it doesn't rewrite the audit trail. internal/ipc gains rules_list/rules_save/rules_delete/rules_toggle. cmd/mitmux gains a rules view ('m' from history) with add/edit/delete/toggle and a small form (name, match, replace, scope, regex). Verified live against real external traffic, not just local echoes: a request-scope rule rewriting User-Agent, confirmed via httpbin.org's own header echo that the origin received the rewritten value while curl sent the real one; a response-scope rule rewriting the Server header, confirmed the client actually received the rewritten value; disabling a rule confirmed via a follow-up request that it stops applying; and throughout, history continued showing the pre-rule original on both sides, confirming the capture/transform split holds. --- PLAN.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'PLAN.md') diff --git a/PLAN.md b/PLAN.md index 80537e1..745511c 100644 --- a/PLAN.md +++ b/PLAN.md @@ -51,3 +51,15 @@ hudsucker) - same problem, worth studying even though this build is Go. boundaries, not just per-connection ones). - CA install UX per OS (Linux/macOS/Windows trust stores) - Whether WebSocket interception is v1 or a later addition +- Step 6 match-and-replace shipped headers-only. Body rules are a + separate, harder problem: request-body capture currently relies on + streaming the body straight from the client connection to the + upstream write (that's what makes it exact, byte for byte); a body + rule needs to materialize, transform, and re-send it instead, which + means deciding what "exact" even means for a rule-modified request + before touching that path again. Also still single-line-text-field + limited in the TUI (bubbles/textinput can't hold a literal CRLF), so + even with header rules, injecting a brand-new header line via the + form isn't possible yet - only rewriting/removing existing ones. The + underlying engine (rules.ApplyHeaders) already supports arbitrary + text-block edits; it's specifically the form UI that's constrained. -- cgit v1.2.3