https://bz.apache.org/bugzilla/show_bug.cgi?id=60251
Bug ID: 60251
Summary: mod_remoteip discards additional address when
mod_rewrite rule is triggered
Product: Apache httpd-2
Version: 2.4.23
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: mod_remoteip
Assignee: [email protected]
Reporter: [email protected]
I've been testing this on a Debian Jessie build (apache 2.4.10), as well as a
Debian Stretch build (apache 2.4.23), with the same results.
In my configuration, mod_remoteip has a single internal trusted proxy, and
X-Forwarded-For is evaluated for additional IPs. Under normal circumstances, it
correctly "stops" at the first untrusted IP, which becomes REMOTE_ADDR.
However, when a mod_rewrite rule is triggered, it seems to discard that IP
address and continue moving up the X-Forwarded-For header, making the second
untrusted IP become the REMOTE_ADDR.
I'm including what I believe is the relevant configuration, but let me know if
further details are needed:
RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy ::1
DocumentRoot /app/httpdocs
<Directory /app/httpdocs>
Require all granted
AllowOverride None
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-s
RewriteRule ^.*$ index.php
</Directory>
In the following tests, I'll connecting from localhost, which is ::1 (the
defined RemoteIPInternalProxy). My index.php file is just echoing out the
relevant $_SERVER variables.
In the first case, I hit /index.php directly, which does NOT trigger a
RewriteRule. The REMOTE_ADDR becomes the right-most untrusted IP address,
3.3.3.3. This is, I believe, the correct behavior:
# curl -H "X-Forwarded-For: 1.1.1.1, 2.2.2.2, 3.3.3.3"
http://localhost/index.php
X-Forwarded-For: 1.1.1.1, 2.2.2.2
REMOTE_ADDR: 3.3.3.3
Now, if I hit an invalid URL, the RewriteRule is triggered and rewritten to
index.php. It appears that 3.3.3.3 is then discarded:
# curl -H "X-Forwarded-For: 1.1.1.1, 2.2.2.2, 3.3.3.3"
http://localhost/invalidurl
X-Forwarded-For: 1.1.1.1
REMOTE_ADDR: 2.2.2.2
----
To show additional behavior, here's a more complicated example that shows that
additional InternalProxies AND TrustedProxies are evaluated after the untrusted
IP is discarded:
RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy ::1
RemoteIPTrustedProxy 100.100.100.0/24
RemoteIPProxiesHeader X-Trusted-Proxies
In the first case, the trusted proxy is added to the X-Trusted-Proxies header,
and REMOTE_ADDR becomes the first untrusted IP (3.3.3.3). This is the correct
behavior:
# curl -H "X-Forwarded-For: 1.1.1.1, 2.2.2.2, 100.100.100.2, ::1, 3.3.3.3,
100.100.100.1" http://localhost/index.php
X-Forwarded-For: 1.1.1.1, 2.2.2.2, 100.100.100.2, ::1
X-Trusted-Proxies: 100.100.100.1
REMOTE_ADDR: 3.3.3.3
But again, by triggering a RewriteRule, the 3.3.3.3 address is discarded,
Internal & Trusted proxies seem to be evaluated again (X-Trusted-Proxies is now
100.100.100.2 instead of 100.100.100.1), and the REMOTE_ADDR becomes the second
untrusted IP, 2.2.2.2:
# curl -H "X-Forwarded-For: 1.1.1.1, 2.2.2.2, 100.100.100.2, ::1, 3.3.3.3,
100.100.100.1" http://localhost/invalidurl
X-Forwarded-For: 1.1.1.1
X-Trusted-Proxies: 100.100.100.2
REMOTE_ADDR: 2.2.2.2
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
