Client-forgeable headers emulation lets any client spoof headers forwarded to proxy backends

Vulnerability Details

File: internal/client/handler.go (OnClientConnecting), internal/proxy/http.go (requestHeaders), internal/proxy/grpc.go (requestMetadata), internal/unigrpc/grpc.go (Consume)
Line: handler.go:389,548-552 (e.Headers -> SetEmulatedHeadersToContext), http.go:131-165 (requestHeaders), grpc.go:82-114 (requestMetadata), unigrpc/grpc.go:46 (Headers: req.Headers)
CWE: CWE-290 -- Authentication Bypass by Spoofing
Severity: Critical
CVSS: 9.1 -- CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Root Cause

The http_headers / grpc_metadata proxy config options are documented as "List of incoming HTTP header names to forward to the proxy backend" / "List of incoming gRPC metadata keys to forward to the proxy backend" -- implying the value originates from the underlying transport connection (e.g. set by a trusted reverse proxy/API gateway in front of Centrifugo). Operators commonly use this to forward identity/trust headers to their own backend for access-control decisions.

However, the wire protocol used by every Centrifugo transport (protocol.ConnectRequest, field headers) includes a headers map populated entirely from the connecting client's own message (its JSON connect command, or for gRPC, its ConnectRequest protobuf field) -- not from real transport-level HTTP headers. Centrifugo copies this client-supplied map verbatim into ConnectEvent.Headers, then into an "emulated headers" context value used by every proxy type (connect, refresh, subscribe, publish, rpc, sub_refresh, map_publish, map_remove, shared_poll_refresh) for the entire connection lifetime. Any header name in the operator's allowlist is forwarded to the backend with the client's own chosen value, unless a header of the exact same name also happens to be present on the genuine underlying HTTP request. For the unidirectional gRPC transport specifically there is no HTTP request at all, so there is no possible override -- the client-controlled value always wins.

Attack Scenario

1. Operator configures a connect proxy with http_headers: ["x-trusted-user"] (or any header name their backend uses for caller identity/trust).
2. Attacker connects directly to Centrifugo and sends a connect command containing "headers": {"x-trusted-user": "<any value>"}.
3. Centrifugo forwards X-Trusted-User: <attacker value> to the backend exactly as if a trusted intermediary had set it.
4. The backend, trusting this header per its own design, grants whatever access/identity it associates with that value.

Impact

Full spoofing of any header value the backend trusts for authentication/authorization, for every proxy call type, for the lifetime of the connection -- up to full account/identity impersonation depending on backend logic. No credentials, JWT, or API key required.

Vulnerable Code

// internal/proxy/http.go
func requestHeaders(ctx context.Context, allowedHeaders, allowedMetaKeys []string, staticHeaders map[string]string) http.Header {
    headers := http.Header{}
    for k, v := range staticHeaders { headers.Set(k, v) }
    emulatedHeaders, _ := clientcontext.GetEmulatedHeadersFromContext(ctx) // 100% client-controlled
    for k, v := range emulatedHeaders {
        if slices.Contains(allowedHeaders, strings.ToLower(k)) {
            headers.Set(k, v) // forwarded to backend as a real outgoing HTTP header
        }
    }
    httpHeaders, hasHTTPHeaders := middleware.GetHeadersFromContext(ctx) // real headers, if present
    for k, vv := range httpHeaders {
        if slices.Contains(allowedHeaders, strings.ToLower(k)) {
            headers[k] = vv // only overrides if SAME header name was ALSO on the real request
        }
    }
    ...
}

// internal/unigrpc/grpc.go -- never goes through HTTP middleware, no competing real-header check at all
connectRequest := &protocol.ConnectRequest{
    Token: req.Token, Data: req.Data, Name: req.Name, Version: req.Version,
    Headers: req.Headers, // the gRPC client's own protobuf field
}

Recommended Fix

Document explicitly that http_headers/grpc_metadata values can also be supplied by the connecting client itself via "headers emulation" and are not guaranteed to come from a trusted reverse proxy. Provide a separate allowlist (e.g. trusted_http_headers) populated only from genuine transport-level HTTP headers, never from client-supplied ConnectRequest.headers, for operators who need an unforgeable header. For uniGRPC, consider disabling http_headers forwarding entirely since there is no transport-level header concept to fall back on.

Verification

Dynamically confirmed against the official centrifugo/centrifugo:v6.8.3 Docker image on BOTH the bidirectional WebSocket transport and the unidirectional gRPC transport, using a minimal backend that logs every header it receives:

• WS: connecting with {"connect": {"headers": {"x-trusted-user": "admin-impersonation-via-headers-emulation"}}} resulted in the backend receiving X-Trusted-User: admin-impersonation-via-headers-emulation, despite no such header existing on the real WebSocket upgrade HTTP request.
• uniGRPC: calling the Consume RPC with ConnectRequest(headers={"x-trusted-user": "admin-impersonation-via-unigrpc"}) (zero real gRPC metadata set) resulted in the backend receiving X-Trusted-User: admin-impersonation-via-unigrpc.
• Control tests (no headers field / no metadata) confirmed the header is absent from the backend's request in the baseline case.