tag 683984 +upstream thanks On Tue, Aug 07, 2012 at 12:58:40PM +0200, Sébastien Bocahu wrote: > This is definitely _not_ a misconfiguration issue. > > mod_rpaf is supposed to use the *last* X-Forwarded-For header. > There's a bug which adds some garbage to the remote_ip field, when a > specific request is sent, and a *correct* X-Forwarded-For header added by the > reverse proxy.
This "garbage" is exactly what you allowed to add via crafted request (curl -H ... etc). Why you want to allow so? > (so the request has two X-Forwarded-For headers when it arrives > on the web front end, one is malicious, one is correct from a trusted source). > > A workaround could be stripping the previous X-Forwarded-For headers on the > reverse proxy, but it shouldn't be necessary. Usually, you can just ignore X-Forwarded-For, provided by client. This case covers typical simple frontend+backend setup. Of course, this shouldn't be necessary - but it's a good idea to expose less headers for modification to client, right? > Real impact of this issue can be remote DOS of a LAMP cluster. > What makes you feel that this issue is "very minor" ? See above. Strictly speaking, my point is that setup with modifiable by client X-Forwarded-For header (case where it *should be* allowed, not just "can be" configured so) is rather uncommon. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
