httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 60251] New: mod_remoteip discards additional address when mod_rewrite rule is triggered
Date Thu, 13 Oct 2016 19:20:02 GMT
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: bugs@httpd.apache.org
          Reporter: apringle@gmail.com

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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message