Hi Willy Tarreau! On Tue, Sep 25, 2012 at 10:31:45PM +0200, Willy Tarreau wrote: > > 00000 GET /phpinfo.php?PATH=/????????????? > > 00034+ ?????/&&pid=42 HTTP/1.1 > > ... > > 00622 X-FORWARDED-URI: > > /%D0%9A%D0%B0%D1%82%D0%B0%D0%BB%D0%BE%D0%B3/&pid=42 > > 00691+ > > > > The full request should be like the following: > > GET /phpinfo.php?PATH=/Каталог/&&pid=42 HTTP/1.1 > Even if those bytes don't display well in your terminal, they're > definitely invalid. I'm surprized they were not encoded before > being reported, I'll have to check why. However I suspect they're > the sames as what appears in X-FORWARDED-REQUEST. If so, you'll > note that the component which builds and emits those requests also > does something strange with the double "&" when there was only one > in the original request.
Actually this request is not my fabrication, this is a request from my client's site of our hosting. It worked everything perfectly untill I update haproxy :) His site is based od such requests. I firstly said that i got Apache before haproxy, he sends requests in not encoded. > tcpdump -A is not exploitable because it replaces unprintable chars > with dots. Better use tcpdump -X instead. Also you can safely use > -s0 instead of -s2000. 0 will dump the exact packet size. Willy, i sent you an apart mail with the file with tcpdump. -- BRGDS. Alexey Vlasov.
