Host Header Injection in SPS REST API - Set-Cookie Domain (4383320)

Penetration tests may flag that the SPS REST API uses the "X-Forwarded-Host" request header to set the "Domain" attribute of the session_id cookie. This is by design to support reverse-proxy deployments and does not represent an exploitable vulnerability. We do not plan to change this behavior.

When a request includes a custom "X-Forwarded-Host" header, the API reflects that value in the "Set-Cookie" response:

# curl -I https://<sps-host>/api/ -H "X-Forwarded-Host: example.com"

Set-Cookie: session_id=…; Domain=example.com; HttpOnly; Path=/; Secure

The same response occurs when the equivalent value is supplied via the Host or Forwarded request header.

Status:

This is working by design and no plan to change this behavior.

Why this is not exploitable:

Browser cookie domain matching. 

Per RFC 6265 §5.3, browsers silently discard a Set-Cookie whose Domain attribute does not domain-match the origin they connected to. A cookie with Domain=example.com returned from sps.customer.internal is never stored. The curl-based PoC only proves the server echoes the value; it does not demonstrate browser-side impact.

Browsers do not send X-Forwarded-Host 

This header is injected by reverse proxies, not by end-user browsers. An attacker cannot cause a victim's browser to include this header in a normal request.

No server-side data flow beyond cookie scoping. 

The header value is not reflected in any other response header, redirect target, or response body content.. It does not flow into routing, redirects, cache keys, SQL queries, or any other server-side logic. The generic risks often cited with Host header injection (cache poisoning, SSRF, SQL injection) do not apply.

Why the feature exists:

SPS is commonly deployed behind a reverse proxy or load balancer that sets X-Forwarded-Host to the external-facing hostname. When the external hostname differs from the appliance's internal hostname, the cookie domain must match the external name for session cookies to function correctly. This pattern is standard across web frameworks.

Why we will not change this behavior:

We evaluated several potential mitigations and concluded that all of them introduce more operational risk than the theoretical issue they address.

• SPS has separate admin web and user web interfaces that may run on different domain names and IP addresses. The common mitigation of redirecting to a single canonical domain is not feasible, because the correct redirect target depends on which interface the request was aimed at.
• SPS is frequently deployed in networks with internal DNS servers or local hosts files. Restricting the cookie domain to a configured allowlist would require customers to manually maintain a list of permitted hostnames. This adds administrative overhead, creates fragile configuration, and causes hard-to-diagnose session failures when hostnames change - producing more harm than benefit.

References

• RFC 6265 §5.3 - Storage Model (cookie domain matching rules)