Am 07.11.2014 um 12:24 schrieb Reindl Harald:
Am 07.11.2014 um 12:17 schrieb Cor Bosman:
I changed my plugin to use the rcube_utils function, https://github.com/corbosman/ident
Reindl has a point though, but that should be changed in that function then
it can't
the point of "mod_remoteip" is that you never face the phyiscal IP anywhere in the application, not in the logs and not in apache modules like mod_security if they are implemented correctly
if you read the mod_remoteip docs careful you see that this header can list more than one address (two proxys between the user and your own proxy which adds his physical client ID) and hence it is important which is your own trusted one nad god beware you try to handle that inside the application and making mistakes if the result is used for authentication and permissions
that's why you *never* should deal with that inside a webapp and keep the resposibility by the webserver admin
to make that more clear:
- there are different headers for the proxied IP possible
- hence you configure mod_remoteip to the header *your* trusted proxy adds combined with the *phyiscal* ip of *your* proxy
whatever application implements fuzzy logic here is *vulnerable* by definition because it don't know about "mod_remoteip" and my see one of the other headers which can be randomly injected by the client and get completly ignored by "mod_remoteip"
so the only one you face inside the fuzzy logic is by definition untrusted user input
practical example:
- my reverse proxy adds X-Forwarded-For
- my backend server makes the transition with mod_remoteip based on that
- frankly X-Forwarded-For *don't exist* fro that moment that is no assumption, that's *proven* by phpinfo() 10 seconds ago
- the attacker set HTTP_X_REMOTECLIENT_IP or HTTP_CLIENT_IP
- the fuzzy logic looks if one of that *three* headers is present
- X-Forwarded-For is stripped by mod_remoteip
- the application uses HTTP_X_REMOTECLIENT_IP for authnetication
- you made my properly configured proxy + backend server vulnerable
don't do that - *period* *ANY HEADER IS UNTRUSTED USER INPUT*
it took me enough energy to convince mod_security upstream that they need to adopt it for Apache 2.4 because the previous handling for whitelisting IP's and logging was a showstopper for upgrade to Apache 2.4 and so please don't break the now existing sane environments by playing fuzzy logic and *luck* inside web applications