Project

General

Profile

Actions

Bug #18126

closed

Proxy servers replace REMOTE_ADDR with their own IP

Added by Michael Stucki about 16 years ago. Updated over 12 years ago.

Status:
Closed
Priority:
Should have
Category:
-
Target version:
-
Start date:
2008-02-05
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.2
PHP Version:
4.3
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

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)


Files

bug_7397.diff (2.59 KB) bug_7397.diff Administrator Admin, 2008-02-05 16:51
bug_7397_v2.diff (10.7 KB) bug_7397_v2.diff Administrator Admin, 2008-02-20 10:29
bug_7397_v3.diff (14.8 KB) bug_7397_v3.diff Administrator Admin, 2008-02-21 20:57
bug_7397_v4.diff (16.9 KB) bug_7397_v4.diff Administrator Admin, 2009-07-23 12:45

Related issues 2 (0 open2 closed)

Has duplicate TYPO3 Core - Bug #14210: SSL - SSL Lock HTTPS Proxy ...ClosedChristian Jul Jensen2004-06-17

Actions
Has duplicate TYPO3 Core - Bug #15135: Typo3 backend does not work with reverse proxyClosedChristian Jul Jensen2005-10-20

Actions
Actions #1

Updated by Michael Stucki about 16 years ago

The attached patch should fix the problem. Untested!

Actions #2

Updated by Henning Pingel about 16 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
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_http.c?view=markup

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.

Cheers,
Henning

Actions #3

Updated by Henning Pingel about 16 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.

Cheers,
Henning

Actions #4

Updated by Martin Kutschker about 16 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).

Actions #5

Updated by Gerhard Rupp over 12 years ago

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

Actions

Also available in: Atom PDF