Fix Intruder silently hanging on body-parameter fuzzing

internal/proxy/intrude.go's buildRequest substitutes marker text but
never recalculated Content-Length. A payload's length routinely differs
from the base value it replaces, so any body-parameter fuzzing attack
left a stale Content-Length from the original captured request in every
substituted request. When the declared length is larger than the actual
body sent, the target server blocks waiting for bytes that never
arrive, and each such request eats the full 60s upstreamTimeout before
failing - silently, with no error or warning anywhere. Since body-
parameter fuzzing is one of the most common Intruder use cases and
payload lengths vary within essentially every real attack, this made
most real body-fuzzing attacks take payloads×60s for no visible reason.
Found by a live audit that timed identical attacks: URL-only marker
fuzzing (no body length change) completed in single-digit milliseconds
per payload; the same attack with the marker in a body parameter took
60s per payload.

fixContentLength recalculates an existing Content-Length header to
match the actual body length after substitution, called right after
buildRequest in the Intrude loop. Deliberately narrow: only touches a
request with exactly one Content-Length header and a clean header/body
boundary. Zero found means nothing to fix (unchanged). More than one is
left alone too - a request smuggling test's own deliberately ambiguous
framing, where guessing which one to "fix" would be worse than leaving
both as the user built them.

This is Intruder-specific, not a change to Repeater: what the user
types into Repeater still goes on the wire completely unmodified, no
auto-fixed Content-Length there, same as always. A fuzzed value's
length is a side effect of automated substitution Intruder performs on
the user's behalf, not a deliberate edit the way a Repeater request is.

internal/proxy/intrude_test.go: TestFixContentLength covers recalculating
a stale length, case-insensitive header matching, no-header and
no-boundary no-ops, and the two-headers-left-alone case.

Verified live against a real HTTP target and a real daemon (JSON over
the control socket, not the TUI, for precise timing): a template with
Content-Length declared far larger than any actual substituted body -
the exact hang-triggering direction - completed all 4 payloads in 0.01s
total, and the recorded history entries carry exactly the correct
recalculated Content-Length for each (10/19/11/14, byte-for-byte
matching each actual body).

go build/vet/gofmt/test/mod tidy all clean.

0 files changed, 0 insertions, 0 deletions