Gate forwarded-header trust behind trusted-proxy config (closes #88)

Every rate limiter keyed on httprate.KeyByRealIP, which believes
True-Client-IP, X-Real-IP and the first X-Forwarded-For entry from
any peer. A client could therefore mint a fresh bucket per request
by rotating a spoofed header, or drain another client's bucket by
claiming its address, which left the receiver, login and password
change limits with no value against a deliberate attacker.

The receiver, login and password change limiters now share one key
function: the connection's own address, unless the direct peer is
inside a network listed in the new TRUSTED_PROXIES CIDR list, in
which case the forwarded client address is used. The list is empty
by default, so nothing is trusted until an operator names their
proxy; a set-but-unparseable value aborts startup, matching the
handling of the other parsed variables.

X-Forwarded-For is the only forwarded header read, from any peer.
Reverse proxies append to it but pass other client headers through
verbatim, so believing a single-valued X-Real-IP or True-Client-IP
would hand a client behind the trusted proxy a fresh bucket per
request - the same bypass, inside the deployment TRUSTED_PROXIES
exists to serve. Within a trusted request the chain is walked right
to left, since the rightmost entry is the one the nearest proxy
appended, and the first hop that is not itself a trusted proxy is
taken as the client. A hop that is not a bare address - ip:port, a
bracketed IPv6 literal, the token unknown - ends the walk and the
peer address is used, rather than continuing left into entries the
client controls.

Trusted-proxy prefixes written in IPv4-mapped form are unmapped at
parse time, since peer addresses are unmapped before matching and
such a prefix would otherwise silently never match.

Also folds in two cleanups from the same review: the 429 responder
shared by all three limiters is extracted, and the
RECEIVER_RATE_LIMIT error-path tests now assert that the failure
names the variable and wraps ErrNonPositiveValue rather than only
that some error occurred.

README.md

@@ -95,6 +95,54 @@ TTY detection, and security headers are always applied.
 | `SENTRY_DSN`            | Sentry error reporting DSN          | `""`     |
 | `SESSION_IDLE_TIMEOUT`  | Idle session timeout (Go duration)  | `24h`    |
 | `RECEIVER_RATE_LIMIT`   | Receiver requests/minute per IP per entrypoint | `120` |
+| `TRUSTED_PROXIES`       | CIDRs whose forwarded headers are trusted | `""` (none) |
+
+#### Trusted proxies
+
+`TRUSTED_PROXIES` is a comma-separated list of CIDR blocks (a bare
+address such as `192.168.1.7` is accepted and treated as a single
+host), for example `192.168.1.7, 2001:db8::5`. It decides whose
+`X-Forwarded-For` header the rate limiters believe, so it should name
+the addresses of your reverse proxies and nothing else.
+
+`X-Forwarded-For` is honoured **only** when the connecting peer is
+inside one of these blocks; for every other peer the client identity is
+the connection's own address and the header is ignored. The default is
+the empty list, which trusts nobody — anything else would let any
+client pick its own rate limit bucket, minting a fresh one per request
+or draining someone else's. Set it to the address of your reverse
+proxy, and to nothing wider. A set but unparseable value aborts
+startup.
+
+`X-Real-IP` and `True-Client-IP` are **never** read, from any peer.
+Reverse proxies append to `X-Forwarded-For` but forward other client
+headers verbatim, so a single-valued header is client-controlled even
+behind a trusted proxy.
+
+Within a trusted request, `X-Forwarded-For` is read right to left,
+because the rightmost entry is the one the nearest proxy appended and
+everything left of it may have been written by the client. The first
+hop that is not itself a trusted proxy is taken as the client. A hop
+that is not a bare IP address — `ip:port`, a bracketed IPv6 literal,
+the token `unknown` — ends the walk and the peer address is used
+instead, since past such an entry the chain is not the shape assumed
+here. The peer address is likewise used when the header is absent or
+every hop in it is a trusted proxy.
+
+Two operator requirements follow:
+
+- Your proxy must **append** the peer address to `X-Forwarded-For`
+  (nginx `$proxy_add_x_forwarded_for`, HAProxy `option forwardfor`,
+  Caddy and AWS ALB by default), and must append a bare address with
+  no port.
+- List proxy hosts **only**. Any address inside `TRUSTED_PROXIES`
+  chooses its own rate-limit key: its `X-Forwarded-For` is walked, so
+  it can name a different address on every request to get a fresh
+  bucket each time, or name another client's address to drain that
+  client's bucket. Never list a block that also covers clients — a
+  broad `10.0.0.0/8` on a network where clients live in the same range
+  makes all three limits, including the unauthenticated webhook
+  receiver, silently bypassable by every client in the block.
 
 Sessions are bounded by two independent clocks, and end at whichever
 one runs out first:
@@ -124,8 +172,9 @@ fatal configuration error: webhooker logs the offending variable and
 its value and refuses to start, rather than silently running with a
 substituted default. `PORT=eighty`, `DEBUG=ture`, and
 `RETENTION_SWEEP_INTERVAL=1 hour` all abort startup. `PORT` must
-additionally be a number in the range 1–65535, and
-`RECEIVER_RATE_LIMIT` must be at least 1.
+additionally be a number in the range 1–65535,
+`RECEIVER_RATE_LIMIT` must be at least 1, and every entry in
+`TRUSTED_PROXIES` must be a CIDR block or a bare IP address.
 
 Boolean variables (`DEBUG`, `MAINTENANCE_MODE`) accept exactly the
 spellings Go's `strconv.ParseBool` accepts — `1`, `t`, `T`, `TRUE`,
@@ -802,6 +851,16 @@ legitimate webhook senders). Requests over the limit receive HTTP 429
 with a `Retry-After` header. A set-but-invalid `RECEIVER_RATE_LIMIT`
 value aborts startup rather than silently falling back to the default.
 
+Every limiter here — receiver, login, and password change — identifies
+the client the same way, through one shared key function: the
+connection's own address, unless the peer is listed in
+`TRUSTED_PROXIES`, in which case the forwarded client address is used
+instead. See [Trusted proxies](#trusted-proxies). Deployed without that
+variable set, a client behind a reverse proxy shares one bucket with
+every other client behind the same proxy, which is the safe direction
+to be wrong in: set `TRUSTED_PROXIES` to the proxy's address to get
+per-client limits back.
+
 Finer-grained per-webhook rate limits (configured in the web UI and
 enforced in the webhook handler) can layer on top of this env-level
 abuse limit later; they are tracked as future work.