基于WEB的应用程序安全测试技术

基于WEB的应用程序安全测试技术董安林，武波西安电子科技大学软件工程研究所 陕西西安 （710071）摘 要:随着互联网技术的迅速发展，Web已经对商业、教育、政府和娱乐及我们的工作和生活产生了深远影响，基于Web的应用程序已经有了很大的市场。

但Web应用程序的安全性一直受到程序开发商和用户的关注，本文简要介绍了Web应用程序安全测试中应注意的几个方面及测试技术，从用户登录测试、缓存溢出测试、数据安全测试、客户端测试等方面进行了详细的分析。

关键词:Web应用软件安全测试基于Web的系统测试与传统的软件测试既有相同之处，也有不同的地方，对软件测试提出了新的挑战。

基于Web的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的终端（浏览器）的显示是否合适。

重要的是，还要从最终用户的角度进行安全性和可用性测试。

1前言软件开发过程各阶段都可能产生错误。

据国外对一些大型软件系统的统计，需求分析与设计阶段产生的错误占64％，编码错误占36％。

因此，测试工作越早进行，发现和解决错误的代价越小，风险越小。

根据这个观点，Systeme Evolutif公司提出了“W－模型”，如图１所示。

“Ｗ－模型”由两个“V”重叠而成。

其中一个“V”表示开发过程，另一个“V”表示测试过程。

软件测试的各项测试活动与开发过程的各个阶段相对应。

同样安全性测试也贯穿于软件开发的全过程。

图1软件测试的Ｗ模型在图1所示的模型中，应用系统开发人员一般关注于提供正常工作的应用软件，而测试人员应该从一个用户的角度去考察，看一看是否能打破它。

所以，Web应用系统安全性测试的目标应该是：核实操作者只能访问其所属用户类型已被授权访问的那些功能或数据，同时检测用户操作对应用系统的危害性[1][2]。

2web 应用程序的安全隐患目前基于web的应用系统，大都采用三层体系结构。

如图2所示。

图2 web应用系统三层体系结构三层体系结构中，将整个应用系统分为了表示层、中间层和数据层。

Web应用系统中，每层的各个功能模块都有其自身的安全弱点，在程序运行中，主要有四个方面的安全隐患[2]：客户端（web浏览器、组件）服务器（web应用服务器、数据库服务器等）网络（web应用程序运行的网络环境）事务（web中各种应用）通常，web应用程序运行的网络环境的安全性由IT部门负责，包括防火墙测试、数据的转发、网络流量的监控、病毒防范以及服务器入侵检测等工作。

所以web应用程序的安全测试更多的关注其它三个方面。

对于客户端的安全隐患，一般会有以下有几种：java脚本、cookie、客户端设置等。

服务器端的安全隐患主要是拒绝服务攻击，可以通过压力测试、缓存溢出测试等方法进行测试；当然服务器端包括整个web应用程序中，最根本的安全隐患就是软件的bug，虽然应用程序无法完全避免bug，但我们可以通过测试、调试等手段使bug的安全隐患减少到最小。

事务中的安全隐患很多，常见的如电子欺骗，伪装成合法用户来窃取信息，一般通过用户登录、身份验证等方法进行测试；还有缓存区溢出，脏数据等方面的安全隐患。

3Web应用程序安全测试3.1用户登录测试3.1.1用户名与密码测试在软件研发中，为方便调试程序，开发人员通常在访问权限中，会主动建立一个超级用户账号来完成软件的总体设计与研发。

但在安全设计中，有一个很重要的原则是给用户尽可能少的访问权限以便他们可以执行与其身份相对应的操作，但不能执行非法操作[3]。

如果有超级用户的存在，最终用户就有可能利用此账号进行创建、修改、删除等一系列对数据表的操作，也可利用SQL语句改变URL，从而进行许多恶意的操作。

现在的Web应用系统基本采用先注册，后登录的方式。

对于用户登录和账户密码，可以从以下几个方面进行安全测试：测试有效和无效的用户名和密码，测试是否大小写敏感，是否有最大字符数的限制规则等。

测试重试次数的限制，如果登录失败的次数超过允许值，应用程序将会做出何种反应（譬如拒绝此IP地址在短时间内的登录）。

测试是否可以利用历史登录信息或以前的URL来绕开登录程序。

测试执行添加、删除、修改等动作中是否需要登录操作，退出系统之后的操作是否仍可继续等。

对于用户的认证，可以从以下几个方面进行安全测试：测试是否所有的合法用法都可以访问程序，非法用户都不能访问程序，如果非法用户企图登录，其难易程序有多大。

测试用户密码是否符合指定要求（字符、长度），如果不符合，对有什么影响，新用户自己修改密码后，创建时分配的密码是否会失效。

测试用户账户过期后，是否完全、正确的删除其信息或使其失效。

3.1.2手动修改URL参数的测试我们经常使用SQL调用来访问后台数据库中的数据，通过猜测或查阅历史记录，恶意用户可能会获得合法用户ID和密码列表。

例如，如果我们在应用程序中采用下面的语句进行用户身份的验证：Select * from userInfo where Login=’admin’ and password=’1234’如果非法用户使用下面的ID和密码Username adminPassword no’or1#则用户登录时应用程序后台调用的的SQL语句会变成：Select * from userInfo where Login=’admin’ and password=’ no’or1#’此时，password的值有可能被赋为‘no’or 1，因为＃号可能会使数据库忽略其后的字符。

此时，由于任何值与1进行逻辑或运算，结果为真，所以系统会把该入侵者当作系统管理员，并将返回记录。

这是很可怕的。

还有一种手动修改的方法，例如，我们用合法用户身份登录后，访问的的网页是/djxl/query/460.apsx那么，手动将其修改为http:// /djxl /query/461.aspx会发生什么情况呢，可能会得到一个你没有权力访问的信息。

与此类似，Web应用程序中有很多的数据库访问目的地址是做为URL中的一个参数（出现在？后的字段），这些信息可以轻易地被非法用户得到，甚至猜测与它相邻的地址。

通过手动修改或调用，可能会在未经授权的情况下访问系统。

3.1.3会话超时的测试Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如20分钟）没有点击任何页面，理论上应认为此用户已下线，并需要重新登录才能正常使用。

对于Windows的IIS管理器，会话超时的设置如图3所示：图3 会话超时设置3.2cookie测试通过调用或改变cookie中的值，非法用户能够利用不属于他们的帐号，在无需用户和密码的情况下访问访问此账号的信息，另外，Cookie 是以纯文本的形式在浏览器和服务器之间传送的，任何可以截取 Web 通信的人都可以读取 Cookie。

所以cookie的不安全有可能导致应用程序和数据库的崩溃[3]。

基于Web的应用程序，为了安全，Cookie不应该保存到用户的硬盘上，而应成为用户会话信息的一部分，即采用会话cookie方式，如果用户关闭浏览器或会话超时，该 Cookie 就会被删除。

但会有一个新问题，如果客户端的机器内存不足，cookie（驻留在内存的）可能会被交换出至客户端的硬盘（虚拟内存中）。

此时，浏览器将被异常终止或崩溃，也就是没有正常退出系统，所以cookie很可能没有从虚拟内存中清除，于是会话cookie就有可能暴露在非法用户眼前。

如果应用程序为方便用户操作，使用了Cookies，就必须检查Cookies是否能正常工作。

测试的内容包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。

当然更重要的一点就是Cookies有效期限的测试。

对于Cookies的测试，一般IE的话可以使用IECookiesView170-Snoopy这个工具来测试保存在Cookie的数据。

3.3压力测试压力测试是为了发现在什么条件下Web应用程序的性能会变得不可接受。

也就是测试应用程序会不会崩溃，在什么情况下会崩溃。

非法用户常常使用错误的超常规的数据负载，直到Web应用程序崩溃，接着获得系统的控制权。

在测试环境中，压力测试可以通过改变应用程序的输入以对应用程序施加越来越大的负载并测量在这些不同的输入时性能的改变来实现的。

这种操作也称为负载测试。

负载测试通常描述为一种特定类型的压力测试——增加用户数量以对应用程序进行压力测试。

对应用程序进行压力测试最简单的方法是手工改变输入（客户机数量、需求大小、请求的频率、请求的混合程度等等）并描绘性能的变化。

但是如果有许多输入，或者需要在大的范围内改变输入，那么你可以借助一个自动化的压力测试工具如QALoad、loadrunner 等来完成此测试。

测试的内容有：Web应用程序同时允许多少用户在线？能否处理大批用户同时对同一页面的访问？如果出现异常，会出现什么情况等[4]。

图4是采用loadrunner软件进行事务响应时间测试结果[5]。

图4 事务响应时间测试结果3.4缓存溢出测试Web应用系统中，数据的输入输出很平常，攻击者可能会提交大量数据，试图引起缓存区溢出，当数据输入的大小超过了在程序内存中为其预留的空间大小时就会引起缓存区溢出，处理数据的程序就会运行失败，攻击者即可利用此来使Web应用程序瘫痪[4]。

虽然Web开发者可以使用某种客户端语言（JavaScript或VBScript）的一些内置功能来确保输入值的长度和默许值。

例如最常见的月份输入检测，只允许用户输入1到12之间的值。

在实际运行中，可能用户本身出于安全考虑，关掉了客户端的脚本功能，这样，输入检测就不会再发挥作用，用户可以输入34、99，甚至可能通过修改脚本等方法输入435、23643等任意数字，这就会使Web应用程序的安全服务进程出现问题。

所以就很有必要进行缓存区溢出的测试。

缓存溢出测试可以使用一些工具创造和提交大量数据，如Hailstrom等专门用来发送大量数据的工具，也可以通过脚本语言如Perl等实现。

有一种很直接的方法就是使用粘贴，这样可以把大量的数据发送到缓存区。

3.5脏数据测试脏数据问题属于数据库并发访问而引起不一致问题，即被称为“数据库并发控制过程冲突”，在并发控制过程冲突中，可能会产生三种数据：丢失数据、不可重复读数据和“脏”数据[3]。

并发控制冲突会引起数据的不完整，从而会来带来数据的错误，引发很严重的后果。

在数据库应用系统中，尤其是是一些大型的系统，如银行业务系统，订票系统等应用中，一般会使用数据库的加锁（Locking）技术来进行并发控制。

在脏数据测试中，需要从程序控制的流程和并发控制的逻辑两个方面来考试测试：程序流程测试。

按照数据处理的流程来设计测试的逻辑重点，分析并发控制的操作点，事务锁的使用情况。