Summary | don't blindly trust x-forwarded-for |
Queue | Horde Framework Packages |
Queue Version | FRAMEWORK_3 |
Type | Bug |
State | Resolved |
Priority | 1. Low |
Owners | chuck (at) horde (dot) org |
Requester | uhlar (at) fantomas (dot) sk |
Created | 01/22/2008 (6376 days ago) |
Due | |
Updated | 02/24/2008 (6343 days ago) |
Assigned | 01/22/2008 (6376 days ago) |
Resolved | 02/24/2008 (6343 days ago) |
Github Issue Link | |
Github Pull Request | |
Milestone | |
Patch | No |
Assigned to Chuck Hagenbuch
State ⇒ Resolved
create that patch, please create a new enhancement request.
accept a function that requires global setting of trusted proxies?
present. That would be great, thanks.
accept a function that requires global setting of trusted proxies?
headers should match. When our users log to horde, only conecting IP
is logged and only forwarded IP put into headers, which makes
searching very difficult.
Providing both proxy and forwarded_for IP's is OK, but forwarded IP is
imho only useful if scripts will track trusted proxies as I described
(squid's forwarded_for patch does the same). This requires list of
trusted proxies/networks as horde/imp configuration option.
Another option is to put all IP's of X-Forwarded-For: line to mail, as
special header (X-Forwarded-For) or list of Received: headers (this
could be very useful for spam checkers). If not all, at least the
trusted forwarded IP should be imho there, adding proxy is useful too.
Personally I would set up function for parsing client IP and
x-forwarded-for to provide 1-2 (last and first trusted) IP addresses,
which would be added to logged informations etc
State ⇒ Feedback
list. The two other places we use it that aren't simply in log
messages are in Auth.php (last login info) and MIME_Headers (the
received: header).
I'm guessing that the received header is the one you care about and
I'm inclined to agree; throwing out the proxy address there is dubious
because it's likely to be useful tracking information. What do you
think about including both (the REMOTE_ADDR value, and a parenthetical
that it was forwarded for the value of HTTP_X_FORWARDED_FOR)?
Priority ⇒ 1. Low
Type ⇒ Bug
Summary ⇒ don't blindly trust x-forwarded-for
Queue ⇒ Horde Framework Packages
State ⇒ Unconfirmed
for specifying IP the connection came from. The X-Forwarded-For is
provided by client that can send anything and it will be used.
This results in e.g. mail headers containing internal IP's unreachable
from server telling nothing to the admin.
Please make usage of X-Forwarded-For optional. The best solution
allowing to trust some (e.g. own) proxies would be to have list of
trusted proxies and check REMOTE_ADDR and HTTP_X_FORWARDED_FOR (from
last to first) if they match trusted proxy and use the fuirst
untrusted IP in the list.