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

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Roundcube Development discussion mailing list
[email protected]
http://lists.roundcube.net/mailman/listinfo/dev

Reply via email to