| Gói / sản phẩm | Phiên bản bị ảnh hưởng | Phiên bản đã vá |
|---|---|---|
| github.com/centrifugal/centrifugo | < 6.9.0mọi phiên bản | 6.9.0 |
| github.com/centrifugal/centrifugo/v3 | mọi phiên bản | |
| github.com/centrifugal/centrifugo/v4 | mọi phiên bản | |
| github.com/centrifugal/centrifugo/v5 | mọi phiên bản | |
| github.com/centrifugal/centrifugo/v6 | < 6.9.0 | 6.9.0 |
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)
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.
http_headers: ["x-trusted-user"] (or any header name their backend uses for caller identity/trust)."headers": {"x-trusted-user": "<any value>"}.X-Trusted-User: <attacker value> to the backend exactly as if a trusted intermediary had set it.Bạn đang dùng một trong các sản phẩm này? Quét site để biết có đang lộ phiên bản có lỗ hổng không.
Quét site miễn phí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.
// 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
}
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.
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:
{"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.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.headers field / no metadata) confirmed the header is absent from the backend's request in the baseline case.