Repository navigation
Client DCR: Trusted Hosts can be faked when relying in X-Forwarded-For #41939
Replies: 1 comment 8 replies
|
See https://www.keycloak.org/server/reverseproxy#_trusted_proxies - requests coming from an untrusted client won't have their header values used. |
The proxy-trusted-addresses are compared against the client address on the connection, not the XFF header. It should mean your security team memeber not just set the XFF to an address in the trusted range, but sent the request in such a way that the client connection to Keycloak was made via an address in the trusted range. |
|
Well, the problem here are the proxies in the middle. In kubernetes environments where you have Istio, several proxies in the middle and a sidecar, the ip from the packet is lost:
So comparing to the ip from the connection packet is not useful in all the cases. When you rely on XFF header, it's usually because packet is not reliable at all, so IMHO it doesn't make sense to compare trusted addresses to the connection packet. This is the reason Envoy and Nginx have mechanisms to trust CIDRs to work with XFF exclusively: or you trust in the packet, or you trust XFF, but you can not trust both at the same time. Anyways, my teammate connected from home. I configured that IP to perform the tests, so what I see here is:
I performed another test after that to know more Basically I forced the proxy we have in front of Keycloak to override XFF header, and have JUST the right IP calculated by Envoy using XFF and trusted_CIDRs. In this scenario, the sidecar sends 127.0.0.6 but XFF received only 80.x.x.x, without anything else. The result is XFF just having the proper real-client-ip and Keyclo
8000
ak worked like a charm in that scenario. The right way to do this is one of the following:
I say this because the environments are completely different. The first one is for cloud-y ones, and the other is more suitable for non-proxied ones |
This is currently how it is documented as working.
Relates to #13261 - or do you want to open another issue?
Are you saying that you want a configuration option that even with proxy-headers=xforwarded to disable using the XFF? |
The point is: why do I have to modify the XFF to just give one IP to Keycloak? Doing that I am masking all the previous hops for it
More or less related, yes. But the proposed solution in the first message is not safe as you can literally put whatever you want in the XFF until the request reaches the first trusted proxy, so you can not take the most left IP. For this, there are two safe approaches.
After doing it, you just compare the Trusted Hosts to that real-client-ip, not with the network packet's one. Additionally, I would add another feature flag to choose between getting real-client-ip from the XFF or from the network packet. Something like this to give options to the user depending on the environment Both approaches are covered by Envoy, for example.
If you add these options, that are quite simple to calculate, for sure you have all potential environments covered, so now you have the real client IP, and now you can compare it against Trusted Hosts for Dynamic Client Registration policy :) |
|
For each option you see as a distinct feature, please create a keycloak issue. From there we'll then have to create an enhancement request for quarkus as that is where the logic will actually live. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Before reporting an issue
Area
core
Describe the bug
Hello there,
I have a Keycloak deployed in production, relying in X-Forwarded-For instead of Forwarded headers due to I have a GLB and an Istio gateway in front. Moreover, due to problems with CORS in Keycloak, I have an additional Istio sidecar fixing it. No problem about this, the issue is the following:
Keycloak rely on faked IPs in dynamic client registration feature. When one of the IPs is set in the X-Forwarded-For by another actor from another source, Keycloak is allowing the registration
I understand that for Keycloak is nearly impossible to calculate the real IP because it can not know the number of hops until reaching Keycloak to calculate the potential IP inside XFF header
By the moment we have it mitigated restricting entrance for those IPs using an AuthorizationPolicy in Istio, that is getting the real client-ip properly (saying this just in case others falling in the same bug)
Version
26.3.1
Regression
Expected behavior
One or several of the following:
Be able to configure the number of hops before Keycloak, to discard from right to left the trusted proxies in front of the system when using in X-Forwarded-For header
Be able to trust in a custom header, where we can set directly the real-client-ip using different methods. For example, I have a proxy-wasm plugin that I place in the GLB or in Istio, that calculates really well the IP and is able to set it in a custom header
Actual behavior
For faked origins in the header, it allows Dynamic Client Registration
How to Reproduce?
Anything else?
No response
All reactions