Using PHP as a CGI binary is an option for setups that for some reason do not wish to integrate PHP as a module into server software (like Apache), or will use PHP with different kinds of CGI wrappers to create safe chroot and setuid environments for scripts. This setup usually involves installing executable php binary to the web server cgi-bin directory. CERT advisory » CA-96.11 recommends against placing any interpreters into cgi-bin. Even if the php binary can be used as a standalone interpreter, PHP is designed to prevent the attacks this setup makes possible:
?) is
passed as command line arguments to the interpreter by the CGI
interface. Usually interpreters open and execute the file
specified as the first argument on the command line.
When invoked as a CGI binary, php refuses to interpret the
command line arguments.
Action) are used to redirect requests to documents like
http://my.host/secret/script.php to the
PHP interpreter. With this setup, the web server first checks
the access permissions to the directory /secret, and after that creates the
redirected request http://my.host/cgi-bin/php/secret/script.php.
Unfortunately, if the request is originally given in this form,
no access checks are made by web server for file /secret/script.php, but only for the
/cgi-bin/php file. This way
any user able to access /cgi-bin/php is able to access any
protected document on the web server.
In PHP, runtime configuration directives cgi.force_redirect, doc_root and user_dir can be used to prevent
this attack, if the server document tree has any directories
with access restrictions. See below for full the explanation
of the different combinations.