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