Repository navigation
Clear untrusted proxy headers in the chart's nginx - #511
Conversation
Apply the same header restrictions as Zammad's shipped nginx configuration: clear Forwarded, X-Forwarded-Scheme and X-Forwarded-Ssl on all locations, and X-Forwarded-User and Remote-User on /. With Rails 8.1 (Zammad 7.2.3) an outer Forwarded header leads to IpSpoofAttackError (500). Add cableExtraHeaders. Supersedes #510.
|
No actionable comments were generated in the recent review. Walkthrough
Severity of issue fixed: Medium Merge Risk:
|
Without Forwarded, the scheme comes only from X-Forwarded-Proto. If TLS ends at a proxy in front of the ingress, the ingress reports http and login fails with "CSRF token verification failed!". Like NGINX_SERVER_SCHEME in the Docker image.
What this PR does / why we need it
Supersedes #510. After updating to Zammad 7.2.3, deployments behind a proxy that sets a
Forwardedheader answer with500errors:Cause: Zammad 7.2.3 updated Rails from 8.0 to 8.1.4.1. Rails 8.1
RemoteIpuses the RFC 7239Forwardedheader beforeX-Forwarded-For, and 8.1.4.1 additionally raises if both headers name different clients. The chart's nginx setsCLIENT_IPand appends toX-Forwarded-For, but passes an outerForwardedheader through untouched, so Rails sees two conflicting hop chains.Zammad already solved this in its own nginx and Apache configurations (since 7.2.0, #6305 in zammad/zammad): its reverse proxy configuration is authoritative, so
Forwarded,X-Forwarded-SchemeandX-Forwarded-Sslare cleared. The Docker images pick that up automatically, but the chart has its own nginx configuration and never got this change. The same is true forX-Forwarded-UserandRemote-User. Zammad clears both on/, because/auth/ssotakes the login from them. The chart passed both through, so a client could set its own SSO login if SSO is enabled and the ingress doesn't strip them.This PR applies the same restrictions in the chart, so the default configuration is safe without any admin action:
//cable/wsForwardedX-Forwarded-SchemeX-Forwarded-SslX-Forwarded-UserRemote-UserX-Forwarded-Proto, which the ingress sets.zammadConfig.nginx.scheme(""/http/https, likeNGINX_SERVER_SCHEMEin the Docker image): empty keeps the ingress'sX-Forwarded-Proto,httpssets it in all locations. Needed if TLS ends at a proxy in front of the ingress, which previously reported HTTPS only viaForwarded; otherwise login fails with "CSRF token verification failed!".extraHeaders,websocketExtraHeadersand the newcableExtraHeaders(taken from set proxy_set_header Forwarded "" #510) are rendered after the defaults. nginx skips an emptyproxy_set_header, so an SSO setup can deliberately pass on its login header again, e.g.extraHeaders: ['X-Forwarded-User $http_x_forwarded_user'].Which issue this PR fixes
extraHeaders/cableExtraHeaders. Please close set proxy_set_header Forwarded "" #510 when this is merged; closing keywords don't apply to PRs.Special notes for your reviewer
X-Forwarded-User/Remote-Userthrough, and proxies that report HTTPS only viaForwarded/X-Forwarded-Ssl, need a values change. See the upgrade notes.nginx:stable(nginx -tpasses). Requests sending all of the above headers were checked against an echo backend. With default values,/passes none of them on, andX-Forwarded-Protostays. Headers added throughextraHeaders/cableExtraHeadersare passed on again.Checklist
Summary by CodeRabbit
New Features
Upgrade Notes
X-Forwarded-Protounless configured otherwise. On/, SSO-related headers are cleared before configured extra headers are applied.X-Forwarded-Protoand overwrite any SSO headers it passes through.