上一篇：Web服务器的安全和攻击防范(一) >>

Web服务器的安全和攻击防范(二)

可以看到，www.example.server的sunrpc服务开放了对外部机器的连接。这是没有必要的，我们可以安装带有访问控制的rpcbind程序或者配置防火墙阻断它。　　
由于nfs默认值极不合理，把文件系统完全不受保护地以可读写方式显露给外界就成了一种极为常见的错误。下面是一个实例：
# /usr/sbin/kshowmount -e center2.sample-university.net
export list for center2.sample-university.net:
/usr/lib/cobol (everyone)
/usr/sys/inst.images (everyone)
/stadtinf (everyone)
/var/spool/mail (everyone)
/usr/lpp/info (everyone)
/usr/local (everyone)
/pd-software (everyone)
/u1 (everyone)
/user (everyone)
/fix (everyone)
/u (everyone)
/ora rzws01
/install (everyone)
/ora-client 192.168.15.20

所有注明了“everyone”的目录都是向公众开放的，其中包括：保存了数百个用户邮件的“/var/spool/mail”目录，以及用户的主目录“/u”和“/u1”。另外“/usr/local”和“/usr/lib/cobol”也是允许写入的，这使得它很容易被安装上特洛伊木马。任何人都可以进入这个系统，且不会遇到什么值得一提的阻力。我们要讨论的第二类安全问题涉及到服务器公用目录下的私有数据。许多web空间提供商提供的只有“web空间”，它们会把用户ftp目录的根映射到web服务器的根。也就是说，用户可以通过ftp以“/”访问服务器目录“/home/www/servers/www.customer.com/”，同时任何人可以通过url“http://www.customer.com/”访问它，用ftp方式保存的“/password”文件可以通过url“http://www.customer.com/password”访问。如果用户web应用需要保存一些私有的、不能从web访问的数据，则根本无法找到满足要求的位置。

许多web商店把订单日志和调试输出写入一个或多个日志文件，或者用配置文件来保存密码和商品数据。如果这些数据保存到页面文档根目录之下，那么它们就有相应的url而且可以通过web访问。此时攻击者所要做的只是猜出这些文件的名字。只要了解了20种主流在线商店系统的默认设置并正确地识别出目标网站所用的系统，要猜出这些文件名字是相当简单的。　　

如果web服务器既提供私有数据存储又提供公用页面目录，上述问题就不会再出现。例如在这些方案中，ftp根目录“/”映射到“/home/www/servers/www.customer.com/”，但页面文档的根目录却在它的下一级目录“/home/www/servers/www.customer.com/pages”，可以通过ftp以“/pages”形式访问。在这种目录配置下，用户可以另外创建和页面文档根目录平行的目录，然后把敏感数据放到这些目录中。由于这些目录可以通过ftp访问，但不能通过http访问，所以它们是无法通过web访问的。　　

如果系统没有采用上述根目录分离的目录结构，我们还有一种解决问题的办法，即在页面文档根目录下创建专用的私有数据存储目录，如“/shop”，然后在这个目录中创建.htaccess文件，通过.htaccess文件拒绝所有http访问（适用于apache服务器）：
$ cat /shop/.htaccess order deny, allow deny from all

该目录中的文件只能通过ftp传输，因为ftp传输忽略.htaccess文件。但与前面采用页面文档根目录之外独立目录的方法相比，这种方法的风险更多一点，因为如果服务器管理员在服务器主配置文件中意外地关闭了该目录必不可少的“allowoverride limit”优先权，这种保护将不再有效。

上述问题还有各种变化形式。如果一台机器上运行着多个客户网站，那么客户就能够欺骗机器，访问在其自己目录层次之外的路径，例如“/home/www/servers/www.customer.com”目录之外的文件。通常，只需创建各种符号链接（指向保存在用户虚拟服务器之外的文件）就有可能实现这一点。最有可能成为链接目标的是包含文件和私有密匙，这是为了获取数据库密码和其他必须保密的信息（为了让应用能够正常运行这些信息往往以明文形式保存在这类文件中）。其他可能的攻击目标还包括保存在非公用目录中的订单记录和其他有用数据。

把尽可能多的服务隔离运行可以部分地解决这个问题，例如用apache suexec程序的sbox让所有的cgi在隔离的环境以客户的用户id而不是web服务器的用户id运行。另外，许多服务器上运行着ftp服务，例如wu-ftpd，该服务的所有文件传输都是隔离进行的，同样也保护了善意客户的资料避免被其他人偷看。

然而，恶意的客户仍旧能够用cgi程序创建符号链接指向其他用户的存储区域，然后通过它自己的web服务器查看其他人的文件，这是因为在一个运行多个网站的环境中，web服务器无法简单地以隔离方式以及用它为之应答请求的客户的用户id运行。管理员应该配置web服务器以及其他文件传输程序使其不再使用符号链接。在apache上，这可以通过关闭最顶层的“followsymlinks”选项实现（不要在较低的层次上把它重新打开），配置代码示例如下：
< directory / > options -followsymlinks < /directory >

第三类常见的安全问题是cgi程序或php脚本的质量低下，它们信任了来源不可靠的参数，未经严格的检查就立即使用cgi参数。　　

web应用一般包含位于防火墙之内的和防火墙之外的两部分，防火墙之内的如本地的脚本程序、数据库、web服务器以及本地数据文件等。由于这些部件都由管理员直接管理和控制，因此可以认为它们都是可以信任的。web应用的其他组成部分位于防火墙之外，是不可信任的。这主要是指用户的浏览器——如果用户使用浏览器，而且没有为了更方便地控制输入web应用的数据和发现web应用中可能存在的问题而直接在telnet会话中输入web请求。

防火墙是可信任的intranet和不可信任的internet之间的分界线。

所有来自信任分界线之外的数据未经检查就不应该进入web应用，这包括所有传递给cgi脚本的参数，比如：get、post和cookie变量，http_referer、http_user_agent和所有http_*变量，以及所有其他远程生成的变量值。在cgi脚本使用所有这些变量之前，都必须对它们进行合法性检查，这种检查可以确保变量的值确实在预期的范围内。

例如，有些脚本在请求的http_referer正确时就接受表单输入，这是一种常见但错误的编程习惯。脚本用这种机制来防范伪造的请求是徒劳的。毫无疑问，对于攻击者来说，掌握必需的http_referer并将它并入请求的其余部分一起发送是轻而易举的，因此这种保护是没有用的。这种脚本错误在于：在这类调用中必须检查的不仅仅是http_referer值，所有其他值都必须进行检查。

下面这个简单的php程序将输出cgi参数b的值以及http_referer的值：
kris@valiant:~/www < cat test.php
< ?php
print "the value of b is $bn";
print "the value of http_referer is $http_referern";
? >
用telnet连接到80端口，我们能够向上述脚本提供任意的参数值b，同时还可以任意提供http_referer值。我们把下面的几行发送到服务器：
get /~kris/test.php?b=this+is+a+test http/1.0
host: valiant.koehntopp.de
referer: http://www.attacker.com/die_sucker_die.html
下面是完整的会话过程：
kris@valiant:~/www < telnet valiant 80
trying 193.102.57.3...
connected to valiant.koehntopp.de.
escape character is ^].
get /~kris/test.php?b=this+is+a+test http/1.0
host: valiant.koehntopp.de
referer: http://www.attacker.com/die_sucker_die.html
http/1.1 200 ok
date: sat, 08 apr 2000 06:44:02 gmt
server: apache/1.3.9 (unix) (suse/linux) php/4.0rc2-dev mod_ssl/2.4.7 openssl/0.9.4
x-powered-by: php/4.0rc2-dev
connection: close
content-type: text/html
the value of b is this is a test
the value of http_referer is http://www.attacker.com/die_sucker_die.html
connection closed by foreign host. 　　
注意b的值必须以url编码格式输入。要将字符串进行url编码，可使用一个简单的php程序，例如：
kris@valiant:~/www < cat urlencode.php
#! /home/kris/bin/php -q
< ?php
print urlencode($argv[1])."n";
? >
kris@valiant:~/www < ./urlencode.php "this is a test"
this+is+a+test
发送http post请求只是稍微复杂一点：现在应该在这个请求中包含一个合法的content-type头以及正确的内容长度字节数。下面是具体过程：
kris@valiant:~/www < telnet valiant 80
trying 193.102.57.3...
connected to valiant.koehntopp.de.
escape character is ^].
post /~kris/test.php http/1.0
host: valiant.koehntopp.de
referer: http://www.attacker.com/die_sucker_die.html
content-type: application/x-www-form-urlencoded
content-length: 16
b=this+is+a+test
http/1.1 200 ok
date: sat, 08 apr 2000 06:55:11 gmt
server: apache/1.3.9 (unix) (suse/linux) php/4.0rc2-dev
mod_ssl/2.4.7 openssl/0.9.4
x-powered-by: php/4.0rc2-dev
connection: close
content-type: text/html
the value of b is this is a test
the value of http_referer is
http://www.attacker.com/die_sucker_die.html
connection closed by foreign host.
另外一种常见的错误是把内部应用的状态数据通过< input type="hidden" >标记从一个页面传递到另一个页面。把内部应用的状态放到信任界限之外就如把应用的心脏挖出来放到了攻击者的面前。对于如此缺乏安全保障的应用，任何想要摧毁它的攻击者都可以轻易地引导该应用并得到任何想要的效果。应用的状态应该通过会话变量保存在服务器上，永远不应该跨越信任界限。所有的web应用开发平台都有这种机制。例如在php3中，phplib可用于保存会话数据，php4使用的是session_*()调用，asp提供session对象，cold fusion提供几种不同的会话变量。　　

web应用不应该把任何来自信任界线之外的数据直接保存为会话变量：会话变量是可信任的变量，不应该用来保存不可信任的数据。通常，来自外面的数据（比如表单变量的数据）应该先传入检验其合法性的函数。只有当检验函数表示表单提供的数据是安全的，才可以把表单数据复制到会话变量。web应用应该把这种检查集中到一起进行，应用的所有其余部分永远不应该直接接触表单变量，而是应该使用经过检查且确认安全的会话数据。

（）

返回顶部

下一篇：网络安全管理的策略应用 >>