Re: [PHP] virtual() call to CGI script
On Wed, 29 Aug 2001 02:14:10 +1000, "Jason Brooke" <[EMAIL PROTECTED]> wrote: >Another way you might be able to do it is find an environment variable that >is only present when the cgi's are executed by the virtual() call, Could not find any ... >use the apache SetEnvIf directive combined with But that gave me an idea for a solution with .htaccess control, and after some testing, I was able to work it out: My document root .htaccess file includes: SetEnvIf Request_URI "the_cgi_caller\.php$" CGI_REFERER=local And my /cgi subdirectory .htaccess file includes: Order Allow,Deny Allow from env=CGI_REFERER The environment variable CGI_REFERER does not exist unless Apache is processing a request for "the_cgi_caller.php" in document root, and thus requesting any file in the /cgi subdirectory via its URL results in a HTTP Error 403 - Forbidden. And since PHP virtual() causes Apache to execute a sub-request, the environment variable CGI_REFERER *does* exist while the CGI is being called via virtual() from "the_cgi_caller.php" It will be simple to add SetEnvIf lines to .htaccess in document root, one for each .php file which needs to call a CGI with virtual(). This is the solution I was looking for. Thanks for the ideas! Egan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] virtual() call to CGI script
> After testing this I see that:
>
> Apache uses the IP address of the remote host to determine whether to
> allow or deny access.
>
> Even though PHP is running on localhost, and making a request via the
> virtual() function, Apache still knows the IP address of the remote
> host, and uses that.
I didn't think of that
I just did a test on my own server and used
readfile("http:///cgi-bin/test";) where test just prints
getenv("REMOTE_ADDR") and it prints the ip address of eth0, so you'd be able
to do it this way - but I don't think using readfile() is as nice as
virtual() in this case because readfile() performs another literal http
request back to the server causing the use of another httpd process I think,
whereas virtual() probably doesn't
Another way you might be able to do it is find an environment variable that
is only present when the cgi's are executed by the virtual() call, then use
the apache SetEnvIf directive combined with
jason
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] virtual() call to CGI script
On Wed, 29 Aug 2001 00:16:10 +1000, "Jason Brooke" <[EMAIL PROTECTED]> wrote: >It will work in .htaccess if you enable it, or you might even be able to use >something like: > > >(untested again) After testing this I see that: Apache uses the IP address of the remote host to determine whether to allow or deny access. Even though PHP is running on localhost, and making a request via the virtual() function, Apache still knows the IP address of the remote host, and uses that. So what happens is that denying "localhost" makes it impossible to run the CGI at all, unless you are running lynx from a local shell. Not exactly what I had in mind. Unless there is some way that Apache can be tricked into believing a request originates from the IP address of localhost, it appears that allow/deny directives will not solve the problem of preventing direct access to user CGIs. It sounded like a good idea, though! Egan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] virtual() call to CGI script
> We don't define any virtual hosts in httpd.conf; instead, we use a > custom handler hooked into post-read-request. So I won't be able to > define "/path/to/usr/cgi" in httpd.conf. > > But if that concept will work in user .htaccess files, it would be an > improvement over my current techniques. I'll give it a try ... > > Thanks for the idea! > > > Egan Ah ok It will work in .htaccess if you enable it, or you might even be able to use something like: (untested again) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] virtual() call to CGI script
On Tue, 28 Aug 2001 23:38:30 +1000, "Jason Brooke" <[EMAIL PROTECTED]> wrote: >if you're using apache, something along the lines of the following untested >directives should prevent anyone but the localhost (which is where your >virtual() calls should be coming from) from accessing the cgi's via http > > >order deny, allow >deny from all >allow from localhost > We don't define any virtual hosts in httpd.conf; instead, we use a custom handler hooked into post-read-request. So I won't be able to define "/path/to/usr/cgi" in httpd.conf. But if that concept will work in user .htaccess files, it would be an improvement over my current techniques. I'll give it a try ... Thanks for the idea! Egan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] virtual() call to CGI script
if you're using apache, something along the lines of the following untested directives should prevent anyone but the localhost (which is where your virtual() calls should be coming from) from accessing the cgi's via http order deny, allow deny from all allow from localhost > Thanks for the idea, but ... > > That would cause the script to be executed with permissions of the web > server, and for security, that is generally prohibited by the ISP (we > are the ISP). The only exception to that rule is public scripts which > reside in: > > safe_mode_exec_dir = /host/runphp > > and are thus allowed to execute with permissions of the web server. > > To provide for the execution of private user CGIs, each user has their > own /cgi directory. Apache is configured to recognize /cgi in any URL > as an executable CGI, and wraps all user CGIs with SuEXEC, to run them > with permissions of the user, not the web server. > > But of course that means user scripts are accessible via URL. So the > question remains, how to limit their access. > > As the ISP, we could use any feature of the web server for our own > CGIs, but we intentionally avoid that. We have a hosting environment > with a rich set of customer accessible tools, and we demonstrate that > fact by using only those tools ourselves. IOW, we use what we sell. > > I have some techniques for limiting access to user CGIs, but I still > wonder how others have approached this problem ... > > > Egan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] virtual() call to CGI script
On Tue, 28 Aug 2001 16:38:14 +1000, "Jason Brooke" <[EMAIL PROTECTED]> wrote: >> I use the PHP virtual() function to call a CGI script, and that works >> fine. But I need to prevent the CGI from being executed directly, in >> case someone tries to access its URL. >> >> Since HTTP_REFERER is unreliable, I was wondering how others have >> solved this problem ... >move it out of the document tree if you don't want it executed via http, and >use system or exec or something instead of virtual Thanks for the idea, but ... That would cause the script to be executed with permissions of the web server, and for security, that is generally prohibited by the ISP (we are the ISP). The only exception to that rule is public scripts which reside in: safe_mode_exec_dir = /host/runphp and are thus allowed to execute with permissions of the web server. To provide for the execution of private user CGIs, each user has their own /cgi directory. Apache is configured to recognize /cgi in any URL as an executable CGI, and wraps all user CGIs with SuEXEC, to run them with permissions of the user, not the web server. But of course that means user scripts are accessible via URL. So the question remains, how to limit their access. As the ISP, we could use any feature of the web server for our own CGIs, but we intentionally avoid that. We have a hosting environment with a rich set of customer accessible tools, and we demonstrate that fact by using only those tools ourselves. IOW, we use what we sell. I have some techniques for limiting access to user CGIs, but I still wonder how others have approached this problem ... Egan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] virtual() call to CGI script
> I use the PHP virtual() function to call a CGI script, and that works > fine. But I need to prevent the CGI from being executed directly, in > case someone tries to access its URL. > > Since HTTP_REFERER is unreliable, I was wondering how others have > solved this problem ... > > > Egan move it out of the document tree if you don't want it executed via http, and use system or exec or something instead of virtual jason -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP] virtual() call to CGI script
I use the PHP virtual() function to call a CGI script, and that works fine. But I need to prevent the CGI from being executed directly, in case someone tries to access its URL. Since HTTP_REFERER is unreliable, I was wondering how others have solved this problem ... Egan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
