Possible attacks and solutions during php installation in CGI mode

PHP Security-attacks and solutions that may occur during CGI installation. if you do not want to embed PHP into server software (such as Apache) as a module for installation, you can choose to install it in CGI mode. Or use PHP to encapsulate different CGI to create a safe chroot and setuid environment for the code. This installation method usually installs PHP executable files to the cgi-bin directory of the web server. Although PHP can be used as an independent interpreter, it is designed to prevent the following types of attacks:

Access system files: http://my.host/cgi-bin/php? /Etc/passwd question mark (?) in the URL request (?) The following information is transmitted to the CGI interface as the parameter of the name row. Other interpreters will open and execute the file specified by the first parameter in the command line. However, when the PHP interpreter installed in CGI mode is called, it will refuse to interpret these parameters.

Access any directory on the server: the http://my.host/cgi-bin/php/secret/doc.html seems like this, the URL information/secret/doc.html behind the directory where the PHP interpreter is located will be routinely passed to the CGI program for explanation. Usually some web servers will redirect it to the page, such as http://my.host/secret/script.php. If so, some servers first check user 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 user access/secret/script. php permissions: only the permissions of/cgi-bin/php are checked, so that any user who can access/cgi-bin/php can access any files in the web directory. In PHP, the configuration options -- enable-force-cgi-redirect during compilation and the command doc_root and user_dir during runtime can add restrictions to files and directories on the server to prevent such attacks. The following describes the settings of each option.

Scenario 1: run only public files

If all content on the web server is restricted by access by passwords or IP addresses, you do not need to set these options. If the web server does not support redirection, or 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 methods, such as access through a direct http://my.host/cgi-bin/php/dir/script.php or through redirection access http://my.host/dir/script.php.

In Apache, you can use AddHandler and Action statements to set redirection.

Scenario 2: Use the -- enable-force-cgi-redirect option

This compilation option prevents anyone from calling PHP directly through a URL such as a http://my.host/cgi-bin/php/secretdir/script.php. In this mode, PHP will only parse the URL that has passed the web server's redirection rule.

Generally, the redirect settings in Apache can be completed using the following command:

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

This option is only tested under Apache and depends on the non-standard CGI environment variable REDIRECT_STATUS set by Apache in the redirection operation. If the web server does not support any method to determine whether the request is direct or redirection, this option cannot be used, but other methods should be used.

Case 3: Set doc_root or user_dir

It is sometimes considered unsafe to include dynamic content such as scripts and executable programs in the main document directory of the web server. If the script is not displayed as a common HTML document due to configuration errors, it may lead to leakage of intellectual property rights or password information. Therefore, many system administrators set a directory that can only be accessed through php cgi, so that the contents in this directory will only be parsed and not displayed as is.

For cases where the redirection cannot be determined, it is necessary to create a script-specific doc_root directory outside the main document directory.

You can use doc_root in the configuration file or set the environment variable PHP_DOCUMENT_ROOT to define the main directory of the PHP script. If this option is set, PHP will only explain the files in the doc_root directory, and ensure that scripts outside the directory will not be executed by the PHP interpreter (except user_dir mentioned below ).

Another available option is user_dir. When user_dir is not set, doc_root is the only option to control where to open the file. Access like http://my.host /~ The user/doc. php URL does not open files in the user's main directory, but only executes ~ User/doc. php (this subdirectory uses [~] ).

If user_dir is set, such as public_php, it is like http://my.host /~ User/doc. php will execute the doc. php file under the public_php subdirectory in the user's main directory. Assume that the absolute path of the user's home directory is/home/user, the file to be executed will be/home/user/public_php/doc. php.

The setting of user_dir has nothing to do with doc_root, so you can control the main directory and user directory of the PHP script respectively.

Case 4: place the PHP interpreter outside the web Directory

A safe practice is to place the PHP interpreter outside the web directory, for example,/usr/local/bin. The only inconvenience is that the following statement must be added to the first line of each file containing PHP code:

#!/usr/local/bin/php

Change the attributes of these files to executable. That is to say, to process CGI scripts written in Perl, sh, or any other scripting language, use #! The shell-escape mechanism at the beginning to start them.

In this case, to enable PHP to correctly process variables such as PATH_INFO and PATH_TRANSLATED, the -- enable-discard-path parameter must be added when compiling the PHP interpreter.