IBX-11181: Trusted Proxies is not set on Ibexa Cloud

[vidarl]

🎫 Issue	IBX-11181

Related PRs:

• PR for filtering X-Forward-For in varnish and fastly VCLs are comming

Description:

Trusted proxies are not set on Ibexa Cloud when using Fastly. We document (via Upsun,) that user must disable TRUSTED_PROXIES: "REMOTE_ADDR" in .platform.app.yaml (which is correct), but we don’t say or specify how to configure TRUSTED_PROXIES correctly.

And frankly, it is not easy/possible to do via static config given how the Upsun router behaves:

Upsun router behavior:

• Will not filter X-FORWARD-FOR sent by malicious client
• It will add client's IP to X-FORWARD-FOR, appending header if already set ( "1.1.1.1" => "1.1.1.1, 2.2.2.2")
• It will always set a X-Client-IP header ( value is IP of client). Value is also end-user's IP if request is received via Fastly ( doc )
• Will filter Client-Cdn if request is not originating from any supported CDN ( doc )
  • When received from Fastly, value of header will be fastly
• $_SERVER['REMOTE_ADDR'] will be spoofed, will have same value as X-Client-IP

So there is no static IP or IP range you can set as trusted proxies when using Fastly on Upsun. For instance, setting trusted hosts to Fasty's public IP list will not do any good. Thus, Ibexa DXP should automatically detect on Ibexa Cloud if request is received via Fastly

Next, I really doesn't understand the original purpose of TrustedHeaderClientIpEventSubscriber. It basically does this:

• If running on Upsun (formerly known as Platform.sh), the request header X_FORWARDED_FOR will be set (value will be copied from the X-Client-IP request header) and X_FORWARDED_FOR will be set as trusted_headers
• However, this header will still be ignored unless devs somehow also sets trusted_proxies correctly.
• Also, the subscriber can be configured to use some other header than X-Client-IP as source

My next doubt is why there was some need for this in relation to IBX-4046
FYI : Original PR : https://github.com/ibexa/core/pull/165/files

As the Upsun router anyway sets the X-Forward-For header, and devs still needed to set trusted_proxies in config ( which IMO is impossible), the old implementation in TrustedHeaderClientIpEventSubscriber is void.
But it certainly may be that I am missing something important....?

What the new implementation of TrustedHeaderClientIpEventSubscriber does:

• If we are on Ibexa Cloud and request is coming from Fastly, then we declare that the request is received via trusted proxy

For QA:

Maybe do sanity checks with "create Applications for Customer portal" feature, as original implementation of TrustedHeaderClientIpEventSubscriber was implemented in relation to that.

Documentation:

[vidarl]

Suggested change

	final class TrustedHeaderClientIpEventSubscriber implements EventSubscriberInterface
	final class IbexaCloudTrustedProxiesEventSubscriber implements EventSubscriberInterface

Or this is considered a BC ? Class is final though, so maybe not a problem?

[barw4]

We don't care

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[barw4]

As discussed with Vidar Client-Cdn header is stripped by Upsun when request is not coming from trusted CDN (in case we care about security and we do)

[barw4]

Confirmed by Upsun (thanks Vidar for reaching out to them with this question): client can't spoof Client-Cdn header - it should arrive into their docs soon so we know for sure we can trust this header.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud