Bug #18126

Proxy servers replace REMOTE_ADDR with their own IP

Added by Michael Stucki over 9 years ago. Updated over 5 years ago.

Should have
Target version:
Start date:
Due date:
% Done:


TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


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)

bug_7397.diff View (2.59 KB) Administrator Admin, 2008-02-05 16:51

bug_7397_v2.diff View (10.7 KB) Administrator Admin, 2008-02-20 10:29

bug_7397_v3.diff View (14.8 KB) Administrator Admin, 2008-02-21 20:57

bug_7397_v4.diff View (16.9 KB) Administrator Admin, 2009-07-23 12:45

Related issues

Duplicated by Core - Bug #14210: SSL - SSL Lock HTTPS Proxy ... Resolved 2004-06-17
Duplicated by Core - Bug #15135: Typo3 backend does not work with reverse proxy Resolved 2005-10-20


#1 Updated by Michael Stucki over 9 years ago

The attached patch should fix the problem. Untested!

#2 Updated by Henning Pingel over 9 years ago

Hi Michael,

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.

Maybe it is interesting for you to have a look at the X-Forwarded-*: handling in

I know that Apache is not the only web server around, and others might do things in a different way. What do you think? Just my 2 cents.


#3 Updated by Henning Pingel over 9 years ago

Hi Masi,

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.

That's all I can see at the moment without testing it.


#4 Updated by Martin Kutschker over 9 years ago

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).

#5 Updated by Gerhard Rupp over 5 years ago

Our proxy just sends a HTTP_X_FORWARD. This should also be taken into account.

Also available in: Atom PDF