PHP安全性漫谈

一、apache server安全性设置

1、以Nobody用户运行

一般情况下,Apache是由Root 来安装和运行的。如果Apache Server进程具有Root用户特权,那么它将给系统的安全构成很大的威胁,应确保Apache Server进程以最可能低的权限用户来运行。通过修改httpd.conf文件中的下列选项,以Nobody用户运行Apache 达到相对安全的目的。
User nobody
Group# -1

2、ServerRoot目录的权限

为了确保所有的配置是适当的和安全的,需要严格控制Apache 主目录的访问权限,使非超级用户不能修改该目录中的内容。Apache 的主目录对应于Apache Server配置文件httpd.conf的Server Root控制项中,应为:
Server Root /usr/local/apache

3、SSI的配置

在配置文件access.conf 或httpd.conf中的确Options指令处加入Includes NO EXEC选项,用以禁用Apache Server 中的执行功能。避免用户直接执行Apache 服务器中的执行程序,而造成服务器系统的公开化。

Options Includes Noexec

4、阻止用户修改系统设置

在Apache 服务器的配置文件中进行以下的设置,阻止用户建立、修改 .htaccess文件,防止用户超越能定义的系统安全特性。

AllowOveride None
Options None
Allow from all

然后再分别对特定的目录进行适当的配置。

5、改变Apache 服务器的缺省访问特性

Apache 的默认设置只能保障一定程度的安全,如果服务器能够通过正常的映射规则找到文件,那么客户端便会获取该文件,如http://local host/~ root/ 将允许用户访问整个文件系统。在服务器文件中加入如下内容:

order deny,ellow
Deny from all

将禁止对文件系统的缺省访问。

6、CGI脚本的安全考虑

CGI脚本是一系列可以通过Web服务器来运行的程序。为了保证系统的安全性,应确保CGI的作者是可信的。对CGI而言,最好将其限制在一个特定的目 录下,如cgi-bin之下,便于管理;另外应该保证CGI目录下的文件是不可写的,避免一些欺骗性的程序驻留或混迹其中;如果能够给用户提供一个安全性 良好的CGI程序的模块作为参考,也许会减少许多不必要的麻烦和安全隐患;除去CGI目录下的所有非业务应用的脚本,以防异常的信息泄漏。

7、SSL链接加密

以上这些常用的举措可以给Apache Server 一个基本的安全运行环境,显然在具体实施上还要做进一步的细化分解,制定出符合实际应用的安全配置方案。

二、PHP安全性设置

服务器并不能阻止所有的安全问题,例如程序漏洞问题、用户输入表单问题、PHP文件权限问题等。
也可以通过一些手段来迷惑黑客或者别有用心者。
1、程序代码漏洞问题

很多 PHP 程序所存在的重大弱点并不是 PHP 语言本身的问题,而是编程者的安全意识不高而导致的。因此,必须时时注意每一段代码可能存在的问题,去发现非正确数据提交时可能造成的影响。


代码如下:

<?php
unlink ($evil_var);
fwrite ($fp, $evil_var);
system ($evil_var);
exec ($evil_var);
?>

必须时常留意你的代码,以确保每一个从客户端提交的变量都经过适当的检查,然后问自己以下一些问题:

此脚本是否只能影响所预期的文件?
非正常的数据被提交后能否产生作用?
此脚本能用于计划外的用途吗?
此脚本能否和其它脚本结合起来做坏事?
是否所有的事务都被充分记录了?
在写代码的时候问自己这些问题,否则以后可能要为了增加安全性而重写代码了。注意了这些问题的话,也许还不完全能保证系统的安全,但是至少可以提高安全性。

还可以考虑关闭 register_globals,magic_quotes 或者其它使编程更方便但会使某个变量的合法性,来源和其值被搞乱的设置。

2、用户输入表单问题

验证用户输入的任何数据,保证PHP代码的安全。
注意1:JS只是为了提高来访用户的体验而产生的,而不是验证的工具。因为任何一个来访的用户都可能会,也有可能无意间就禁用了客户端脚本的执行,从而跳过这层验证。所以我们必须在PHP的服务器端程序上检验这些数据。
注意2:不要使用$_SERVER['HTTP_REFERER']这个超级变量来检查数据的来源地址,一个很小的菜鸟黑客都会利用工具来伪造这个变量的数据,尽可能利用Md5,或者rand等函数来产生一个令牌,验证来源的时候,验证这个令牌是否匹配。

3、PHP文件权限问题

PHP 被设计为以用户级别来访问文件系统,所以完全有可能通过编写一段 PHP 代码来读取系统文件如 /etc/passwd,更改网络连接以及发送大量打印任务等等。因此必须确保 PHP 代码读取和写入的是合适的文件。 请看下面的代码,用户想要删除自己主目录中的一个文件。假设此情形是通过 web 界面来管理文件系统,因此 Apache 用户有权删除用户目录下的文件。


代码如下:

<?php
$username = $_POST['user_submitted_name'];
$homedir = "/home/$username";
$file_to_delete = "$userfile";
unlink ("$homedir/$userfile");
echo "$file_to_delete has been deleted!";
?>

既然 username 变量可以通过用户表单来提交,那就可以提交别人的用户名和文件名,并删除该文件。这种情况下,就要考虑其它方式的认证:

只给 PHP 的 web 用户很有限的权限。
检查所有提交上来的变量。
以下是更加安全的文件名和变量的验证和检查:


代码如下:

<?php
$username = $_SERVER['REMOTE_USER'];
$homedir = "/home/$username";

if (!ereg('^[^./][^/]*$', $userfile))
die('bad filename');

if (!ereg('^[^./][^/]*$', $username))
die('bad username');
?>

4、隐藏PHP扩展名

一般而言,通过隐藏的手段提高安全性被认为是作用不大的做法。但某些情况下,尽可能的多增加一份安全性都是值得的。

一些简单的方法可以帮助隐藏 PHP,这样做可以提高攻击者发现系统弱点的难度。在 php.ini 文件里设置 expose_php = off ,可以减少他们能获得的有用信息。

另一个策略就是让 web 服务器用 PHP 解析不同扩展名。无论是通过 .htaccess 文件还是 Apache 的配置文件,都可以设置能误导攻击者的文件扩展名:

# 使PHP看上去像其它的编程语言
AddType application/x-httpd-php .asp .py .pl

# 使 PHP 看上去像未知的文件类型
AddType application/x-httpd-php .bop .foo .133t

# 使 PHP 代码看上去像 HTML 页面
AddType application/x-httpd-php .htm .html

要让此方法生效,必须把 PHP 文件的扩展名改为以上的扩展名。这样就通过隐藏来提高了安全性,虽然防御能力很低而且有些缺点。

三、Mysql数据库安全性设置

PHP 本身并不能保护数据库的安全。下面的章节只是讲述怎样用 PHP 脚本对数据库进行基本的访问和操作。记住一条简单的原则:深入防御。保护数据库的措施越多,攻击者就越难获得和使用数据库内的信息。正确地设计和应用数据库可以减少被攻击的担忧。

1、数据库设计问题

应用程序永远不要使用数据库所有者或超级用户帐号来连接数据库,因为这些帐号可以执行任意的操作,比如说修改数据库结构(例如删除一个表)或者清空整个数据库的内容。以下截图的用户设置是危险的。



应该为程序的每个方面创建不同的数据库帐号,并赋予对数据库对象的极有限的权限。仅分配给能完成其功能所需的权限,避免同一个用户可以完成另一个用户的事情。这样即使攻击者利用程序漏洞取得了数据库的访问权限,也最多只能做到和该程序一样的影响范围。

2.数据库连接问题
把连接建立在 SSL 加密技术上可以增加客户端和服务器端通信的安全性,或者 SSH 也可以用于加密客户端和数据库之间的连接。如果使用了这些技术的话,攻击者要监视服务器的通信或者得到数据库的信息是很困难的。

3.数据库数据的加密

SSL/SSH 能保护客户端和服务器端交换的数据,但 SSL/SSH 并不能保护数据库中已有的数据。SSL 只是一个加密网络数据流的协议。

如果攻击者取得了直接访问数据库的许可(绕过 web 服务器),敏感数据就可能暴露或者被滥用,除非数据库自己保护了这些信息。对数据库内的数据加密是减少这类风险的有效途径,但是只有很少的数据库提供这些加密功能。

对于这个问题,有一个简单的解决办法,就是创建自己的加密机制,然后把它用在 PHP 程序内,最常见的例子就是把密码经过 MD5 加密后的散列存进数据库来代替原来的明文密码。

代码如下:

<?php
$query = sprintf("INSERT INTO users(name,pwd) VALUES('%s','%s');",
addslashes($username), md5($password));
$result = pg_query($connection, $query);
$query = sprintf("SELECT 1 FROM users WHERE name='%s' AND pwd='%s';",
addslashes($username), md5($password));
$result = pg_query($connection, $query);
if (pg_num_rows($result) > 0) {
echo 'Welcome, $username!';
} else {
echo 'Authentication failed for $username.';
}
?>

4、SQL注入问题

直接 SQL 命令注入就是攻击者常用的一种创建或修改已有 SQL 语句的技术,从而达到取得隐藏数据,或覆盖关键的值,甚至执行数据库主机操作系统命令的目的。这是通过应用程序取得用户输入并与静态参数组合成 SQL 查询来实现的。下面将会给出一些真实的例子。

代码如下:

<?php
$query = "SELECT id, name, inserted, size FROM products
WHERE size = '$size'
ORDER BY $order LIMIT $limit, $offset;";
$result = odbc_exec($conn, $query);
?>

可以在原来的查询的基础上添加另一个 SELECT 查询来获得密码:
union select '1', concat(uname||'-'||passwd) as name, '1971-01-01', '0' from usertable;
假如上述语句(使用 ' 和 --)被加入到 $query 中的任意一个变量的话,那么就麻烦了。

这些攻击总是建立在发掘安全意识不强的代码上的。所以,永远不要信任外界输入的数据,特别是来自于客户端的,包括选择框、表单隐藏域和 cookie。就如上面的第一个例子那样,就算是正常的查询也有可能造成灾难。

永远不要使用超级用户或所有者帐号去连接数据库。要用权限被严格限制的帐号。
检查输入的数据是否具有所期望的数据格式。PHP 有很多可以用于检查输入的函数,从简单的变量函数和字符类型函数(比如 is_numeric(),ctype_digit())到复杂的 Perl 兼容正则表达式函数都可以完成这个工作。

如果程序等待输入一个数字,可以考虑使用 is_numeric() 来检查,或者直接使用 settype() 来转换它的类型,也可以用 sprintf() 把它格式化为数字。

一个更安全的防止SQL注入的分页显示方法:

代码如下:

<?php
settype($offset, 'integer');
$query = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;";
$query = sprintf("SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET %d;",
$offset);
?>

(0)

相关推荐

  • PHP 编程安全性小结

    规则 1:绝不要信任外部数据或输入 关于 Web 应用程序安全性,必须认识到的第一件事是不应该信任外部数据.外部数据(outside data) 包括不是由程序员在 PHP 代码中直接输入的任何数据.在采取措施确保安全之前,来自任何其他来源(比如 GET 变量.表单 POST.数据库.配置文件.会话变量或 cookie)的任何数据都是不可信任的. 对用户输入进行清理的一个简单方法是,使用正则表达式来处理它. 规则 2:禁用那些使安全性难以实施的 PHP 设置 已经知道了不能信任用户输入,还应该知

  • 浅谈php安全性需要注意的几点事项

    在放假之初,我抽时间看了<白帽子讲web安全>,吴翰清基本上把web安全中所有能够遇到的问题.解决思路归纳总结得很清晰,也是我这一次整体代码安全性的基石. 我希望能分如下几个方面来分享自己的经验 把握整站的结构,避免泄露站点敏感目录 在写代码之初,我也是像很多老源码一样,在根目录下放上index.php.register.php.login.php,用户点击注册页面,就跳转到http://localhost/register.php.并没有太多的结构的思想,像这样的代码结构,最大的问题倒不是安

  • 解析php安全性问题中的:Null 字符问题

    由于 PHP 的文件系统操作是基于 C 语言的函数的,所以它可能会以您意想不到的方式处理 Null 字符. Null字符在 C 语言中用于标识字符串结束,一个完整的字符串是从其开头到遇见 Null 字符为止. 以下代码演示了类似的攻击:Example #1 会被 Null 字符问题攻击的代码 复制代码 代码如下: <?php$file = $_GET['file']; // "../../etc/passwd\0"if (file_exists('/home/wwwrun/'.$

  • PHP临时文件的安全性分析

    一.简介 临时文件,顾名思义是临时产生的文件,且文件的生命周期很短. 然而,很多应用的运行都离不开临时文件,临时文件在我们电脑上无处不在,主要有以下几种形式的临时文件: 1.文件或图形编辑程序,所生成的中间文件 2.数据库查询时,生成的临时缓存文件,提供之前的结果数据而,以减少再次访问数据库的代价:通常用于远程数据库或远程xml的服务 3.文件被上传后在服务端的临时储存,其文件名为php的全局变量$_FILES['userfile']['tmp_name']的值 4.在http请求中,用于存放s

  • 制作安全性高的PHP网站的几个实用要点

    大家都知道PHP已经是当前最流行的Web应用编程语言了.但是也与其他脚本语言一样,PHP也有几个很危险的安全漏洞.所以在这篇教学文章中,我们将大致看看几个实用的技巧来让你避免一些常见的PHP安全问题. 技巧1:使用合适的错误报告 一般在开发过程中,很多程序员总是忘了制作程序错误报告,这是极大的错误,因为恰当的错误报告不仅仅是最好的调试工具,也是极佳的安全漏洞检测工具,这能让你把应用真正上线前尽可能找出你将会遇到的问题. 当然也有很多方式去启用错误报告.比如在 php.in 配置文件中你可以设置在

  • PHP session会话的安全性分析

    从而达到方便快捷的目的,但是它在存储信息的时候往往会有一些敏感的东西,这些东西可能成为被攻击的目标,如银行的账号.信用卡事务或档案记录等.这就要求在编写代码的时候必须采取安全措施来减少攻击成功的可能性. 主要的安全措施有以下两个方面. 1.防止攻击者获取用户的会话ID. 获取会话ID的方式很多,攻击者可以通过查看明文通信来获取,所以把会话ID放在URL中或者放在通过未加密连接传输的Cookie中是很危险的:还有在URL中(作为_get()参数)传递会话ID也是不安全的,因为浏览器历史缓存中会存储

  • PHP中使用addslashes函数转义的安全性原理分析

    本文实例讲述了PHP中使用addslashes函数转义的安全性原理分析.分享给大家供大家参考.具体分析如下: 先来看一下ECshop中addslashes_deep的原型 复制代码 代码如下: function addslashes_deep($value) {     if (empty($value)) {         return $value;  //如为空,直接返回;     } else {         return is_array($value) ? array_map(

  • php下过滤html代码的函数 提高程序安全性

    以下为过滤HTML代码的函数: 复制代码 代码如下: function ihtmlspecialchars($string) { if(is_array($string)) { foreach($string as $key => $val) { $string[$key] = ihtmlspecialchars($val); } } else { $string = preg_replace('/&((#(\d{3,5}|x[a-fA-F0-9]{4})|[a-zA-Z][a-z0-9]{

  • Apache下禁止特定目录执行PHP 提高服务器安全性

    如果用的是Apache服务器,还可以通过配置来禁止该目录下的PHP文件的访问,有两种方式: 方式一:.htaccess控制,适用于没有服务器管理权限. 在可写文件夹的目录下,建一个.htaccess文件,内容为: 复制代码 代码如下: <Files ~ ".php"> Order allow,deny Deny from all </Files> 方式二:修改Apache配置文件,适用于有服务器管理权限. 配置中增加如下内容: 复制代码 代码如下: <Di

  • Session的工作机制详解和安全性问题(PHP实例讲解)

    我们先简单的了解一些http的知识,从而理解该协议的无状态特性.然后,学习一些关于cookie的基本操作.最后,我会一步步阐述如何使用一些简单,高效的方法来提高你的php应用程序的安全性以及稳定行. 我想大多数的php初级程序员一定会认为php默认的session机制的安全性似乎是有一定保障的,事实恰好相反 – php团队只是提供了一套便捷的session的解决方案提供给程序员使用,至于安全性的话,应该由程序员来加强,这是应用程序开发团队的责任.因为,这里面的方法很多,可以这么说吧,没有最好,只

随机推荐