Possible attacks and workarounds for PHP installation in CGI mode

If you do not want to embed PHP into the server-side software (such as Apache) as a module installation, you can choose to install in CGI mode. Or use PHP for different CGI wrappers to create a secure chroot and SETUID environment for your code. This installation typically installs the PHP executable file to the Web server's Cgi-bin directory. Although PHP can be used as a standalone interpreter, it is designed to prevent the following types of attacks:

Access System files: HTTP://MY.HOST/CGI-BIN/PHP?/ETC/PASSWD The information that follows the question mark (?) in the URL request is passed to the CGI interface as the parameter for the named row. The other interpreter opens and executes the file specified by the first parameter on the command line. However, when the PHP interpreter installed in CGI mode is called, it refuses to interpret these parameters.

Access any directory on the server: http://my.host/cgi-bin/php/secret/doc.html like this, the URL information behind the directory where the PHP interpreter resides/secret/doc.html will be routinely passed to CGI programs and explain them. Typically some Web servers redirect it to a page, such as http://my.host/secret/script.php. If this is the case, some servers will first check the user's access to the/secret directory before creating page redirection on the http://my.host/cgi-bin/php/secret/script.php. Unfortunately, many servers do not check the user's access to/secret/script.php, only the permissions of/cgi-bin/php, so any user who has access to/cgi-bin/php can access any file in the Web directory. In PHP, compile-time configuration options--enable-force-cgi-redirect and runtime configuration directives Doc_root and User_dir can add restrictions to files and directories on the server to prevent such attacks. The settings for each option are explained in more detail below.

Scenario One: Only open files are run

You do not need to set these options if all content in the Web server is restricted by passwords or IP addresses. If the Web server does not support redirection, or if the Web server cannot communicate with PHP to make access requests more secure, you can specify the--enable-force-cgi-redirect option in the Configure script. In addition, make sure that the PHP program does not rely on other means of invocation, such as through direct http://my.host/cgi-bin/php/dir/script.php access or through redirected access to http://my.host/dir/script.php.

In Apache, redirects can be set using the AddHandler and Action statements.

Scenario two: Using the--enable-force-cgi-redirect option

This compilation option prevents anyone calling PHP directly from a URL such as http://my.host/cgi-bin/php/secretdir/script.php. PHP only resolves URLs that have passed the Web server's redirection rules in this mode.

Typically, the redirection settings in Apache can be done with the following directives:

Action php-script/cgi-bin/phpaddhandler php-script. php

This option is only tested under Apache and relies on the non-standard CGI environment variable redirect_status that Apache has set in the redirect operation. If the Web server does not support any way to determine whether a request is direct or redirected, this option cannot be used, but should be done in other ways.

Scenario Three: Setting Doc_root or User_dir

The inclusion of dynamic content such as scripts and executable programs in the Web server's main document directory is sometimes considered an unsafe practice. Failure to execute the script as a normal HTML document, due to misconfiguration, can result in the disclosure of intellectual property or password information. So many system administrators will set up a directory that can only be accessed through PHP CGI, so that the contents of the directory will only be parsed and not displayed as is.

It is necessary to create a script-specific Doc_root directory outside of the main document directory for situations in which it is not possible to determine whether or not to redirect.

You can define the PHP script home directory by doc_root within the configuration file or by setting the environment variable php_document_root. If this is set, PHP will only interpret the files in the Doc_root directory and ensure that scripts outside the directory are not executed by the PHP interpreter (except for the user_dir below).

Another option that is available is user_dir. When User_dir is not set, Doc_root is the only option to control where files are opened. Accessing the URL, such as http://my.host/~user/doc.php, does not open the file under the home directory, but only executes the ~user/doc.php under the Doc_root directory (this subdirectory starts with [~]).

If User_dir is set, such as public_php, a request like http://my.host/~user/doc.php will execute the doc.php file under the public_php subdirectory of the user's home directory. Assuming that the absolute path to the user's home directory is/home/user, then the executed file will be/home/user/public_php/doc.php.

User_dir settings are independent of doc_root, so you can control both the home directory and the user directory of the PHP script separately.

Scenario Four: PHP interpreter placed outside the web directory

A very safe way is to put the PHP interpreter in a place outside the Web directory, such as/usr/local/bin. The only inconvenience to do this is to include the following statement in the first line of each file containing PHP code:

#!/usr/local/bin/php

Also change the properties of these files to executable. In other words, like processing CGI scripts written in Perl or SH or any other scripting language, use the #! Starting with the Shell-escape mechanism to start them.

In this case, in order for PHP to correctly handle variables such as Path_info and path_translated, you must add the--enable-discard-path parameter when compiling the PHP interpreter.

