|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2002-08-26 15:14 UTC] php_new at jdc dot parodius dot com
I believe the following to be a severe bug which relates directly to PHP4 and Apache 1.3:
For those of you unfamiliar with HTTP, there is an HTTP command called "CONNECT" which is intended for use with HTTP proxying. Via telnet, one can test for proxy capability by doing the following (input is in bold):
$ telnet www.somehost.com 80
Trying ###.###.###.###...
Connected to www.somehost.com.
Escape character is '^]'.
CONNECT www.google.com:80 HTTP/1.0
Host: www.somehost.com
Now hit [Enter] twice. If your Apache configuration is proper (and without mod_proxy installed), you should get the following response:
HTTP/1.1 405 Method Not Allowed
However, this is where the bug shows up. Here are the pre-requisites for it to appear:
Must have PHP4 module loaded.
Must have index.php listed in Apache DocumentIndex directive.
Must have index.php file in the DocumentRoot of the website you're connecting to (in the above example, www.somehost.com).
The result of the above HTTP CONNECT when all of the above pre-requistes are met:
HTTP/1.1 200 OK
[HTTP headers here]
[Contents of parsed index.php here; as if visiting the website!]
An HTTP response code of 200 should only be sent when the request was legitimate -- a HTTP CONNECT should not be legitimate just because the website in question has an index.php file. You can literally rename index.php to something else (even index.html!) and a correct HTTP status of 405 is returned. I have read the HTTP RFC in full, and it is fairly vague when it comes to dealing with HTTP CONNECT -- however, the Status code section applies to all sections, therefore a Status code of 200 on an HTTP CONNECT when mod_proxy is not loaded is incorrect.
Again, this only happens with mod_php4 installed.
So why is this a big deal? Well, a slew of online services use proxy scanners to ensure legitimate clients are being used to communicate with their servers; proxy scanners are also used for IRC. The scanners look for a status code of 200 on an HTTP CONNECT.
There is a workaround, which is to add the following to your server configuration:
<Location />
<Limit CONNECT>
Order deny,allow
Deny from all
</Limit>
</Location>
This bug may be directly related to bug #17424.
Footnote: If this is traced back to be a flaw in Apache's DSO code, then I expect to see it reported as such, so I can forward this entire thread on to the Apache team and make them deal with it. Thanks.
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sun Nov 02 19:00:02 2025 UTC |
Well can you tell me why it is "severe"? Okay it is maybe not correct that it reacts on any string but basicly why should it not react on TINTE / HTTP/1.0 This could be a valid request if the server has loaded mod_tinte v1.0 or whatever. If you dislike the feature you can always check for a valid ("from your point of view") request method from within your scripts.I added the following three lines to Apache's mod_dir. This is ugly but works fine for me. Unless there's another way to prevent mod_php4 from getting invoked I'll use this on my machines. Dunno if this will work with mod_proxy but I guess so. --- src/modules/standard/mod_dir.c +++ src/modules/standard/mod_dir.c @@ -118,4 +118,7 @@ static int handle_dir(request_rec *r) { + if (r->method_number == M_CONNECT) + return HTTP_NOT_IMPLEMENTED; + dir_config_rec *d = (dir_config_rec *) ap_get_module_config(r->per_dir_config, Use it at your own risk and only with Apache 1.3(.28)!