Files
webhooker/internal/handlers/webhook.go
clawbot a0e4e32e3e
All checks were successful
check / check (push) Successful in 2m52s
Bound every slog line against client-chosen text (closes #176)
MaxBodySize logged r.URL.Path untruncated at WARN, and routes.go
registers it ahead of RequireAuth, so an unauthenticated
POST /source/<8 KB>/edit with an oversize declared Content-Length wrote
attacker-chosen text of attacker-chosen length into the operator's log,
for the cost of a request with no body. The 2,560-byte per-line budget
#146 established did not reach it: that budget lives in the access-log
field capping and this is a separate slog call.

The capping mechanism moves out of internal/middleware into
internal/logfield so there is one budget and one implementation rather
than a second ad-hoc truncation. Truncate and EncodedBytes are
unchanged; the access log now spends logfield.MaxBytes where it spent
maxLogFieldBytes.

The sweep the issue asked for found five more call sites of the same
shape, all reachable unauthenticated, all now capped: the CSRF 403
(also registered ahead of RequireAuth), the rate limiters' 429 (the
per-entrypoint receiver limiter is unauthenticated), RequireAuth's own
DEBUG line, the unknown-entrypoint DEBUG line on the receiver, and the
failed-login DEBUG lines. DEBUG being off by default is not a bound: an
operator turning it on to diagnose a flood must not thereby hand the
flood an unbounded write. Every other slog call in the tree was read
and judged; the PR body lists all of them, including the ones left
alone and why.

MaxBodySize stays ahead of RequireAuth. An oversize body should be
refused before the request buys a cookie decrypt and a session load,
and rejecting first is what keeps an unauthenticated flood from
choosing how much session work the process does. The ordering and what
it costs are now written at the registration, on maxFormBodySize.

MaxAccessLogLineBytes is restated as the ceiling on every slog line
carrying a client-supplied value, not just the access log's: each of
these lines carries strictly fewer client-supplied fields than the
access log does, so none can be wider. That is asserted per line under
both handlers rather than argued. Two writers are called out as NOT
covered, so the figure is not read as more than it is: the log delivery
target, which exists to emit the whole event and is deliberate, and
GORM's default logger, which prints the interpolated SQL to stdout on a
record-not-found and is unbounded on the receiver and login lookups.
That second one is a real defect this audit turned up and is filed
separately as #178, not fixed here.

Tests drive 8 KB of client-chosen text at all six sites, through both
handlers internal/logger can install and through each character they
escape — including a bare C0 control, which costs six bytes on the line
against the one it cost to send and is the case a raw-byte budget
breaks on first. Each holds the encoded line to the ceiling, holds the
whole flood's output to what that ceiling allows, and asserts the
markers at the far end of the input are absent, so a value that merely
happened to be short cannot pass. internal/logfield gains a test that
measures the per-rune charge against what the handlers really emit over
roughly 3,000 code points on each, so an undercharged rune fails a test
instead of quietly falsifying the ceiling.

Verified by mutation: reverting the MaxBodySize cap alone fails 12
subtests with a 16,583-byte line against the 2,560 ceiling; reverting
the other five fails 70; budgeting raw bytes instead of encoded ones
fails 23 across three packages.
2026-08-17 23:43:26 +00:00

7.7 KiB