When requesting the clients REMOTE_ADDR, it can happen that there is a proxy in between server and client, which replaces the value with his own IP, and puts the original IP in HTTP_X_FORWARDED_FOR instead.

It is important that this value should only be regarded if there is really a proxy, as the field could be faked easily otherwise, which is a problem when it comes to security checks...(issue imported from #M7397)

History

I guess HTTP_X_FORWARDED_FOR is only present in case of a reverse proxy, not a forward proxy, right? Otherwise I would be surprised. So we are only talking about reverse proxies here, right?

The question IMHO is which problem should be solved by your patch. There are different possible reverse proxy scenarios. Your patch will improve the situation, but will not fix those problems that arise when the reverse proxy is used as an SSL proxy (and web sites are proxyied in virtual sub folders of the main SSL proxy domain). For the SSL proxy case I think I have found a solution (that also works for others) and I could assist you here. But maybe this is a different problem from your point of view?

I think the best approach would be to find a solution that takes into account all three HTTP_X_Forwarded_... parameters that are used by the Apache module mod_proxy / mod_proxy_ . If we do this we could claim that the TYPO3 core fully supports reverse proxying with Apache mod_proxy... Otherwise there will be patches necessary again and again.

First of all thank you for providing the patch. I didn't test it yet, I only looked at the source code. Unfortunately I will not have time to test the patch until the beginning of March. I will get back to you then.

I learned from your patch that HTTP_X_FORWARDED_FOR and HTTP_X_FORWARDED_HOST can contain a comma separated list of multiple entries. This I didn't know. But we should check if we need the first or the last entry of the array. Currently array_pop returns the last entry, but the comments says "use first IP found in list". Which one is the initial IP of the visitor?

It's nice that you check IP addresses for validity. HTTP_X_FORWARDED_FOR could contain any crap. ;-)

I think for SSL proxy support you also need to modify HTTP_REFERER in case of proxy. If $TYPO3_CONF_VARS['SYS']['doNotCheckReferer'] is set to false, there will be trouble because of an illegal referer value, I tested this with TYPO3 4.1.5.

Patch v3 has a way to define which multivalue to use: first, last or none (default). It's up to the admin to figure out what his proxy does.

As for the referer: it doesn't matter if it's SSL or not. Only the hist is being compared. If your proxy sends a HTTP_X_FORWARDED_HOST header it will be used and can therefor be compated against the host of the referer (which contains always the ext. URL).