mirror of
https://github.com/coder/coder.git
synced 2026-09-21 20:51:01 +08:00
Bobby Ho
166d92ba73
## Summary `httpapi.Read` decoded request bodies with no size limit, so a single request could allocate memory without bound. This adds a 4 MiB default ceiling, leaves the endpoints that legitimately need more explicitly exempted, and counts the rejections so a limit set too tight is visible. This is the first of three PRs split out of #28048, covering the endpoints that answer in `codersdk.Response` shape. The OAuth2 decode paths (RFC 6749, RFC 7591) and the SCIM ones (RFC 7644) answer in their own error shapes and follow in separate PRs, along with the lint rule that pins the invariant. Closes PLAT-463. Remediates SEC-416 (CWE-770, CVSS 7.5) and SEC-392. ## Problem `httpapi.Read` calls `json.NewDecoder(r.Body).Decode(value)` with no ceiling, and no middleware in the chain bounds body size. The exposure is pre-authentication: login, OTP, and first-user creation all read a body before any authorization decision is reached. The existing rate limiter bounds request *rate*, which is orthogonal to the memory a single admitted request may consume. ## Fix `Read` is split into `Read` and `ReadLimit`. `ReadLimit` wraps `r.Body` in an `http.MaxBytesReader` and keeps the existing decode and validate logic; `Read` delegates to it with a new `DefaultMaxRequestBodyBytes` of 4 MiB, which covers the 124 remaining non-test callers at a single site. `http.MaxBytesReader` composes as tightest-wins, so the handlers that pre-wrapped their own bodies pass their limit to `ReadLimit` rather than wrapping, and each keeps its previous ceiling byte for byte. That matters most for the bulk secrets import at `8 * MaxSecretsFileBytes`: an unconditional wrap inside `Read` would have silently halved it to the default. `TestImportUserSecretsBodyLargerThanDefaultLimit` is the regression guard for that specific failure, and `TestMaxBytesReaderNesting` pins the composition behavior the whole requirement rests on. Every rejection site calls `httpapi.RecordRequestBodyLimit`, which names the limit that tripped on the request's existing log line and marks the request so `coderd_api_requests_too_large_total{reason="request_body"}` counts body rejections apart from the 413s coderd answers for other causes, such as agent log storage overflow. A limit set too tight for a legitimate payload therefore surfaces without waiting for a user report. The limit is a constant rather than a deployment option: an operator raising it to unblock something would reopen the vulnerability as configuration, where a security scan will not find it. A legitimate 413 is answered with a targeted `ReadLimit` on that endpoint. ## Behavior change `POST /api/v2/files` now answers 413 rather than 400 when a request body exceeds `HTTPFileMaxBytes`. It installed that bound already but reported the rejection as a read failure, which leaked the stdlib `http: request body too large` string through `Detail` and kept the largest limit in the tree off the metric. The separate 413 for an oversized expanded archive is unchanged. The task log snapshot endpoint now answers 413 rather than 400 when its 64 KiB cap is exceeded. Routing it through `ReadLimit` also changes its decode-failure message from "Failed to decode request payload." to "Request body must be valid JSON.", which is what every other endpoint answers. Its tests are updated to match both. `coderd_api_requests_too_large_total` is new, so there is no existing query to migrate. It counts the 413s coderd answers, labeled `method`, `path`, and `reason`. `reason="request_body"` is a rejection by one of the limits above; `reason="other"` is a 413 that has nothing to do with body size, such as agent log storage overflow. ## Reading this The commits are ordered to be read in sequence. Commits 1 and 2 are the security fix; commits 3 to 5 are the observability consequences, and commit 3 is the one that touches dashboards. Commit 7 documents the limit on the REST API reference index. Commits 6 and 8 add and revert an exhaustive `@Failure 413` annotation pass, which buried the fix under its regenerated swagger, and cancel out.
53 lines
2.0 KiB
Go
53 lines
2.0 KiB
Go
package httpapi
|
|
|
|
import (
|
|
"context"
|
|
|
|
"cdr.dev/slog/v3"
|
|
"github.com/coder/coder/v2/coderd/httpmw/loggermw"
|
|
)
|
|
|
|
// RequestBodyLimitTracker records that a request was rejected for exceeding a
|
|
// request body size limit.
|
|
//
|
|
// Middleware installs it on the way in and reads it on the way out, so a
|
|
// rejection written deep in a handler can be attributed without that handler
|
|
// knowing a metric exists. It is written and read on the request's own
|
|
// goroutine, so it needs no synchronization.
|
|
type RequestBodyLimitTracker struct {
|
|
exceeded bool
|
|
}
|
|
|
|
// Exceeded reports whether a body size limit rejected this request.
|
|
func (t *RequestBodyLimitTracker) Exceeded() bool {
|
|
return t.exceeded
|
|
}
|
|
|
|
type requestBodyLimitContextKey struct{}
|
|
|
|
// WithRequestBodyLimitTracker returns a context carrying tracker.
|
|
func WithRequestBodyLimitTracker(ctx context.Context, tracker *RequestBodyLimitTracker) context.Context {
|
|
return context.WithValue(ctx, requestBodyLimitContextKey{}, tracker)
|
|
}
|
|
|
|
// RecordRequestBodyLimit reports the body size limit that rejected this
|
|
// request. It names the limit on the request's existing log line and marks the
|
|
// request so middleware can tell a body size rejection from the other reasons
|
|
// coderd answers 413, such as agent log storage overflow.
|
|
//
|
|
// The limit goes on the existing log line rather than one of its own: a caller
|
|
// can produce 413s at will, so a dedicated line is attacker-controlled log
|
|
// volume.
|
|
//
|
|
// Every site that answers 413 because a request body exceeded a limit must call
|
|
// this, and a site answering 413 for any other reason must not. ctx must be the
|
|
// request's context, which is what carries both the logger and the tracker.
|
|
func RecordRequestBodyLimit(ctx context.Context, limit int64) {
|
|
if requestLogger := loggermw.RequestLoggerFromContext(ctx); requestLogger != nil {
|
|
requestLogger.WithFields(slog.F("max_request_body_bytes", limit))
|
|
}
|
|
if tracker, ok := ctx.Value(requestBodyLimitContextKey{}).(*RequestBodyLimitTracker); ok {
|
|
tracker.exceeded = true
|
|
}
|
|
}
|