GHSA-5mq7-rwhj-4fh9: Medium severity nuget/Steeltoe.Security.Authorization.Certificate vulnerability
Summary
When Steeltoe's certificate-based authorization (UseCertificateAuthorization) is configured, the default configuration of the middleware relies on the X-Client-Cert HTTP header to identify the client certificate, without verifying private-key possession. This header is not stripped by common Cloud Foundry routers (like Gorouter or Envoy) on inbound requests.
Impact
An attacker who obtains the public certificate of an application instance in the target organization or space can spoof the X-Client-Cert header. This allows the attacker to bypass SameOrg and SameSpace authorization policies, granting unauthorized access to protected endpoints for the duration of the certificate's validity period.
Affected configuration
- The application uses AddOrgAndSpacePolicies() and UseCertificateAuthorization() for inter-service authorization. - Inbound requests are not restricted to a known trusted proxy source IP. - The application's endpoints are network-accessible to the attacker (e.g., exposed to the internet via a public Cloud Foundry route, or the attacker has access to the internal Cloud Foundry network).
Mitigations
If an immediate upgrade to a patched version is not possible:
- Restrict UseCertificateForwarding to trusted proxy source IPs using ForwardedHeadersOptions.KnownProxies and KnownNetworks. - Change the forwarding header to X-Forwarded-Client-Cert so that Cloud Foundry Gorouter and Envoy header stripping mechanisms apply to inbound untrusted requests. - Add a secondary authorization layer (e.g., a shared secret or mutual TLS at the proxy layer) for sensitive endpoints. - Ensure the application is not bound to a public route unless explicitly required. Use Cloud Foundry internal routes (e.g., .apps.internal) and container-to-container network policies to strictly limit network access to intended internal clients.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
nuget/Steeltoe.Security.Authorization.Certificateto a version that resolves this vulnerability.Fixed in 4.3.0 - Configuration
Change the forwarding header used to carry client certificates from `X-Client-Cert` to `X-Forwarded-Client-Cert` so Cloud Foundry Gorouter and Envoy header stripping mechanisms apply to inbound untrusted requests.
Proxy / request header handling (Cloud Foundry Gorouter / Envoy) Use X-Forwarded-Client-Cert header for client certificates = X-Forwarded-Client-Cert - Configuration
Configure `UseCertificateForwarding` so it only trusts proxy sources defined in `ForwardedHeadersOptions.KnownProxies` and `ForwardedHeadersOptions.KnownNetworks`.
.NET middleware (Steeltoe) certificate forwarding authorization UseCertificateForwarding with ForwardedHeadersOptions KnownProxies/KnownNetworks = Restrict to trusted proxy source IPs - Configuration
Use Steeltoe certificate-based authorization by configuring `AddOrgAndSpacePolicies()` and `UseCertificateAuthorization()` for inter-service authorization.
Steeltoe inter-service authorization AddOrgAndSpacePolicies() and UseCertificateAuthorization() = Enabled/configured - Compensating control
Ensure the application is not bound to a public route unless explicitly required; instead use Cloud Foundry internal routes (e.g., `.apps.internal`) and enforce container-to-container network policies to strictly limit network access to intended internal clients.
- Compensating control
Add a secondary authorization layer for sensitive endpoints (e.g., a shared secret or mutual TLS at the proxy layer).
Event History
Frequently Asked Questions
Is a default deployment affected?
The default configuration of the certificate authorization middleware relies on the X-Client-Cert HTTP header. Exposure additionally requires AddOrgAndSpacePolicies() and UseCertificateAuthorization(), no restriction of inbound requests to trusted proxy source IPs, and attacker network access to the application endpoints.
What does an attacker need to exploit this?
An attacker needs the public certificate of an application instance in the target organization or space and the ability to send requests to the application's reachable endpoints. They can then spoof the X-Client-Cert header without proving possession of the certificate's private key.
What access could a successful exploit provide?
An attacker can bypass SameOrg and SameSpace authorization policies and access protected endpoints. The unauthorized access lasts for the validity period of the spoofed certificate.
Are Cloud Foundry routers sufficient to prevent header spoofing?
No. Common Cloud Foundry routers, including Gorouter and Envoy, do not strip the X-Client-Cert header from inbound requests according to the advisory.