ID: 19113 Comment by: uhlar at fantomas dot sk Reported By: php_new at jdc dot parodius dot com Status: Bogus Bug Type: Apache related Operating System: FreeBSD PHP Version: 4.3.2-dev New Comment:
Isn't there a possibility to check for valid/supported methods? maybe such check should be in apache, but couldn't php check what method it's processing instead of processing CONNECT as GET? Previous Comments: ------------------------------------------------------------------------ [2003-08-17 12:52:22] messi at toxis dot com Reproduced with Apache 2.0.47 (prefork) and PHP 4.3.2 (module/apache2handler) on Linux with an /index.php in docroot of first vhost. httpd.conf: DirectoryIndex index.php index.html index.htm AddType application/x-httpd-php .php CONNECT www.google.com:80 HTTP/1.0 --> HTTP/1.1 200 OK TINTE / HELLO/1.0 --> HTTP/1.1 200 OK I can't believe this. Please tell me this is a feature and there is a way to turn this off. Also, please explain to me why this so-called feature is turned on by default. Well, there might be some reasons to introduce a new request method or even a new http-like protocol and that /index.php can handle this but this shouldn't be allowed by default. Thanks in advance. ------------------------------------------------------------------------ [2003-08-06 19:38:21] arafuse at bcexplorers dot com I had to take the code a little further. I don't have mod_proxy/mod_rewrite installed, and I keep getting the following in the log files: 203.98.129.180 - - [05/Aug/2003:17:43:32 -0700] "POST http://64.59.128.220:25/ HTTP/1.1" 200 933 "-" "-" 203.98.129.180 - - [05/Aug/2003:17:43:32 -0700] "POST http://64.59.128.220:25/ HTTP/1.1" 200 933 "-" "-" System: apache 1.3.28, php 4.3.1, RH7.3 ======================================================== <?php if( strtoupper($_SERVER['REQUEST_METHOD'])=="CONNECT"){ header("HTTP/1.1 405 Method Not Allowed"); die(); } if( strtoupper($_SERVER['REQUEST_METHOD'])=="POST") { if (preg_match("/\:(\d+)/", $_SERVER['REQUEST_URI'], $matches)) { if (($matches[1] != '80') && ($matches[1] != '443')) { header("HTTP/1.1 405 Method Not Allowed"); die(); } } } ?> ======================================================== ------------------------------------------------------------------------ [2003-07-07 17:59:18] jesseNO at SPAMhousejunkie dot ca I have also replicated this issue slack 9.0. 1.3.27 / 4.3.2 I have also applied the above fix <snip> <? if( strtoupper($_SERVER['REQUEST_METHOD'])=="CONNECT"){ header("HTTP/1.1 405 Method Not Allowed"); die(); } ?> </snip> I has stopped the issue until php releases the fix ------------------------------------------------------------------------ [2003-06-19 20:10:30] fallenmatt at yahoo dot com this is my temporally fix: i put it in an include file with a nice body (coppied from apache response to connect) and include it on top of index.php files for each virtual server: <? if( strtoupper($HTTP_SERVER_VARS['REQUEST_METHOD'])=="CONNECT"){ header("HTTP/1.1 405 Method Not Allowed"); die(); } ?> you should probably use $_SERVER[] instead... and no empty lines in your include file, otherwise header() gets confused ------------------------------------------------------------------------ [2003-06-19 09:47:51] fallenmatt at yahoo dot com i found this bug affecting my servers too. the severity of it is that spammers scan for open proxies and then don't check that they get smtp connection back, anything that's succesfull request puts the address on their proxy list. the result: i've got basically denial of service attack. My server was getting thousands of requests ("connect x.x.x.x:25) per hours, sometimes hundreds per minute. SInce it does a lot of mysql querries my database gaved up and started throwing can't connect to database errors. it is still a persistent problem. for a time being i check my counters and whenever i get large number of requests from same ip address i just ban it on my firewall. that is not a good sollution so still looking for a way to really fix it. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/19113 -- Edit this bug report at http://bugs.php.net/?id=19113&edit=1
