Microsoft Web Application Stress Tool
Microsoft Web Application Stress Tool 是由微软的网站测试人员所开发,专门用来进行实际网站压力测试的一套工具。透过这套功能强大的压力测试工具,您可以使用少量的Client端计算机仿真大量用户上线对网站服务所可能造成的影响,在网站实际上线之前先对您所设计的网站进行如同真实环境下的测试,以找出系统潜在的问题,对系统进行进一步的调整、设置工作。
Microsoft Web Application Stress具有以下几个特性:
* 可以数种不同的方式建立测试指令:包含以手动、录制浏览器操作步骤、或直接录入IIS的记录文件、录入网站的内容及录入其它测试程序的指令等方式。
* 支持多种客户端接口:标准的网站应用程序C++的客户端,使用Active Server Page 客户端,或是使用Web Application Stress对象模型建立您自定的接口。.
* 支持多用户利用多种不同的认证方式仿真实际的情况,包含了DPA, NTLM 及 SSL等。
* 支持使用动态的cookie仿真定制网站实际运作场景及对话(session)的支持。
* 在客户端的计算机以NT 服务的方式执行仿真的工作,可在不中断测试的情况下将某些客户端的测试计算机删除。
* 透过集中式的Microsoft Web Application Stress 管理员,您可以使用任意数目的客户端计算机同时进行测式的工作。
* 具有Bandwidth throttling (带宽遏流)的功能以仿真用户使用调制解调器上线的效果。
* 内建的query-string 编辑器可帮助您建立name-value pair组合的模板,并可在不同的场景测试中重复使用。
* 可程序化的对象模式让您可以建立您自己的测试客户端。
* 汇总的测试报告及丰富的性能测试资料。
* 支持域名系统(DNS)让您可以测试整个群集(Cluster)的机器。
* 使用Page group的方式来控制文件的组及测试指令的执行程序。
* 可自定的header让您可以仿真各种不同种类的浏览器。
* 可自定的指令延迟让您以更接近真实环境的方式进行测试。
网站测试概述
为了正确使用WAS进行网站的压力测试,您需要对于网站测试的方法有一初步的了解。以下的讨论将包含一些基本的概念以供参考。
网站的测试可大略分成三个主要的类别:
* 网站性能测试 (Performance testing)
* 压力测试下的网站稳定性 (Stability or stress testing)
* 网站承受能力评估 (Capacity planning)
网站性能测试的第一件工作就是使用测试工具对网站加压以测量网站服务器每秒可以承受的请求(Request Per Second) 的最大值。第二件工作就是找出系统性能限制的原因所在,举例来说,CPU、内存、或是后端系统所造成的反应延迟等。
在许多状况下,网站服务器的CPU是主要的性能瓶颈。测试时您可以持续加压直到性能表现开始下降,再慢慢的降低压力的程度。此时您所测试出来的最大性能即为该网站所能达到的最高值。在实际测试时,您可以通过增加压力线程(thread),或是增加执行WAS测试程序的客户端来加压。
在网站服务器端,您可以使用性能监视工具如Performance Monitor来监视如 "System: % Total Processor Time" 及 "Web Service: Connection Attempts/sec" 或 "Active Server Pages: Requests Queued"等指针。如果CPU的资源指针已达到80%到85%,则CPU的处理能力最有可能就是整个系统的瓶颈所在。若是在压力测试的过程中CPU所被使用的比例不高而”Requests Queued”的指针一直居高不下,可能是程序正在调用服务器上的COM组件而这个组件无法有效的执行完所有的命令,因而造成了系统性能的降低。在这种情形下,服务器上的COM组件才是真正的瓶颈。
目前市场上最热门的定制网站应用程序也会对网站的性能表现有重大的影响。WAS包含了数种特性可有效的帮助您测试定制的网站应用程序。例如,您可以建立用户,让WAS可以设置并储存每一个用户的cookie。您也可以使用QueryString 编辑器帮助您建立并储存数个不同的name-value pair以便在每一次执行request时进行测试。
一般的网站测试问题
* 错误的测试平台,和实际上线的 production server(生产环境服务器)不同,无法测出实际的问题。
* 错误的测试指令,无法正确的仿真出实际上线系统真正的反应。
* 线程安全性问题以及不稳定的服务器COM组件。
* Active Server Page 的错误及GLOBAL.ASA 设置的问题。
IBM appscan试用版下载
http://www.ibm.com/developerworks/cn/downloads/r/appscan/
IBM appscan试用版下载时注册界面
https://www.ibm.com/account/profile/cn?page=reg
appscan安装文档
http://wenku.baidu.com/view/b34a1d12a216147917112871.html
1 当前 Web 安全现状
互联网的发展历史也可以说是攻击与防护不断交织发展的过程。目前,全球因特网用户已达 13.5 亿,用户利用网络进行购物、银行转账支付和各种软件下载,企业用户更是依赖于互联网构建他们的核心业务,对此,Web 安全性已经提高一个空前的高度。
然而,现实世界中,针对网站的攻击愈演愈烈,频频得手。CardSystems 是美国一家专门处理信用卡交易资料的厂商。该公司为万事达 (Master)、维萨 (Visa) 和美国运通卡等主要信用卡组织提供数据外包服务,负责审核商家传来的消费者信用卡号码、有效期等信息,审核后再传送给银行完成付款手续。这家公司为超过 10 万家企业处理信用卡信息,每年业务金额超过 150 亿美元。这家已有 15 年历史的公司怎么也没想到,居然有黑客恶意侵入了它的电脑系统,窃取了 4000 万张信用卡的资料。这些资料包括持卡人的姓名、账户号码等。这是美国有史以来最严重的信用卡资料泄密事件。此次攻击事件不仅仅对消费者,对公司造成了巨大的损失,甚至对美国的信用卡产业产生了严重的影响!
1.1 Web 安全的认识误区
然而什么才是 Web 安全呢,或者说什么样的网站才是安全的呢?用户往往有一些常见的误区。
“Web 网站使用了防火墙,所以很安全”
无论是应用级还是端口级的防火墙针对的都是网络层面的攻击,通过设置可访问的端口或者应用,把恶意访问排除在外,然而如何鉴别善意访问和恶意访问是一个问题。访问一旦被允许,后续的安全问题就不是防火墙能应对了。
“Web 网站使用了 IDS,所以很安全”
通过模式识别对网络层面的攻击做出防护措施。然而类似于防火墙,通过利用程序漏洞,通过正常连接进行攻击的访问无法被识别和处理。
“Web 网站使用了 SSL 加密,所以很安全”
SSL 对网站发送和接收的信息都进行加密处理,然而 SSL 无法保障存储在网站里的信息的安全和网站访问者的隐私信息。采用 64 位甚至 128 位 SSL 加密的网站被黑客攻陷的例子举不胜举。
“漏洞扫描工具没发现任何问题,所以很安全”
当前漏洞扫描工具已经被广泛使用去查找一些明显的网络安全漏洞。同理,扫描工具无法对网站应用程序进行检测,无法查找应用本身的漏洞。
“我们每季度都会聘用安全人员(Pen Tester)进行审计,所以很安全”
人为的检测考察不仅仅效率低,不可控因素也较多,同时对于代码变更频繁的今天,Pen Tester 也无法满足全面的安全需求
然而这些方法远远不能保障 Web 应用的安全,针对应用层面的攻击可以轻松的突破防火墙保护的网站。例如:最为常见的 SQL 注入攻击表现层面完全是正常的数据交互查询。对于防火墙或者入侵检测系统而言,这是最为正常的访问连接,没有任何特征能够说明此种访问连接存在恶意攻击。所以,一些简单的 SQL 注入语句就可以使得装备昂贵网络安全设备的网站被轻松攻破。
1.2 Web 安全现状
令人惊诧的是,几乎所有关注 Web 安全领域的人都会存在着上面我们阐述的误区,而当前 Web 的安全现状也同时证明了这些误区的普遍性。“防火墙、IDS 是主要安全手段,SSL 保证了安全性,…”与之相对的是:互联网发展到今天,75%的安全问题竟然是出现在应用程序本身。正如上面介绍的 SQL 注入攻击一样,这是防火墙、SSL、入侵检测系统无法预防、解决、和应对的!
如下图所示,目前安全投资中,只有 10%花在了如何防护应用安全漏洞,而这却是 75%的攻击来源――10% Vs 75%,这是多么大的差距!这也是造成当前 Web 站点频频被攻陷的一个重要因素。
图 1. 当前安全现状统计分析图
那么,什么样的防护才是一个完整的解决方案呢?通过附图 2 我们可以看到,一个完整的 Web 防护不仅仅包含了常见的 IDS、Firewall 等防护手段,更需要针对应用本身做好安全防护,这也是解决 75%安全漏洞的手段。那么什么样的攻击是防火墙、IDS、或者 SSL 无法应对的呢,他们又是如何利用应用本身的漏洞进行攻击的呢?下面我们将做详细的阐述。
图 2. Web 应用的网络防护
常见针对 Web 应用攻击的十大手段
目前常用的针对应用漏洞的攻击已经多达几百种,最为常见的攻击为下表列出的十种。
十大攻击手段 应用威胁 负面影响 后果
跨网站脚本攻击 标识盗窃,敏感数据丢失… 黑客可以模拟合法用户,控制其帐户。
注入攻击 通过构造查询对数据库、LDAP 和其他系统进行非法查询。 黑客可以访问后端数据库信息,修改、盗窃。
恶意文件执行 在服务器上执行 Shell 命令 Execute,获取控制权。 被修改的站点将所有交易传送给黑客
不安全对象引用 黑客访问敏感文件和资源 Web 应用返回敏感文件内容
伪造跨站点请求 黑客调用 Blind 动作,模拟合法用户 黑客发起 Blind 请求,要求进行转帐
信息泻露和不正确的错误处理 黑客得到详细系统信息 恶意的系统检测可能有助于更深入的攻击
被破坏的认证和 Session 管理 Session token 没有被很好的保护 在用户推出系统后,黑客能够盗窃 session。
不安全的木马存储 过于简单的加密技术导致黑客破解编密码 隐秘信息被黑客解密盗窃
不安全的通讯 敏感信息在不安全通道中以非加密方式传送 黑客可以通过嗅探器嗅探敏感信息,模拟合法用户。
URL 访问限制失效 黑客可以访问非授权的资源连接 黑客可以强行访问一些登陆网页、历史网页。
我们通过注入缺陷(Injection Flaws,排名第二的攻击)对攻击原理进行一下说明。
在网站的应用中需要应用到大量的数据库查询检索等功能,例如最简单的例子是网站登陆,用户需要输入登陆名称和密码进行登陆认证。在早期的开发中通常使用最为简单的 select 语句实现此功能,即 select * from users where username = “XXXX” and password = “XXXX”( 假设数据库 user 表名称为 users,用户名和密码字段名称为 username 和 password)。通过截取用户在文本框中录入的字符串,再进行拼接,形成 select 语句,最终如果表 users 中有符合此条件的记录(即该用户名和密码),系统将会返回有效记录,从而允许登陆系统中。
然而,此开发方法隐藏了一个巨大的漏洞,黑客可以通过 SQL 注入攻击攻入网站。如下图所示,黑客在登陆界面录入的不是用户名,而是一串字符串 (’or 1=1 --
)。黑客的目的是在原本应该录入用户的地方录入了一串字符串,导致整个 select 语句发生了变化:select * from users where username=’’or 1=1
。熟知 Select 语句的人知道,在条件语句中,无论用户名称是否正确,由于 1
=1
永远是正确的,所以 select 将会将所有 users 表中的数据返回。最终的结果是,黑客登陆到这个系统中。通过 SQL 注入攻击,黑客可以轻松的敲入一些 sql 语句登陆进网站、对隐秘数据进行查询等等。
图 3. 攻击举例
通过上述原理描述我们可以看到,对于 SQL 注入攻击无论是防火墙还是入侵检测系统都无法预防和阻止,唯一的办法是将应用本身的漏洞关闭。例如通过参数的传递配合存贮过程来实现数据库查询,这比动态的构建 sql 语句安全很多。比如在 ASP.net 中通过下面的程序将会避免攻击:
' Visual Basic example
Dim DS As DataSet
Dim MyConnection As SqlConnection
Dim MyCommand As SqlDataAdapter
Dim SelectCommand As String = "select * from users where username = @username"
...
MyCommand.SelectCommand.Parameters.Add(New SqlParameter("@username",
SqlDbType.NVarChar, 20))
MyCommand.SelectCommand.Parameters("@username").Value = UserNameField.Value
// C# example
String selectCmd = "select * from Authors where state = @username";
SqlConnection myConnection = new SqlConnection("server=...");
SqlDataAdapter myCommand = new SqlDataAdapter(selectCmd, myConnection);
myCommand.SelectCommand.Parameters.Add(new SqlParameter("@username",
SqlDbType.NVarChar, 20));
myCommand.SelectCommand.Parameters["@username"].Value = UserNameField.Value;
除了注入缺陷攻击,常见的应用攻击还有跨网站脚本攻击、恶意文件执行攻击、不安全直接对象应用攻击、跨站点请求伪造攻击、信息泄漏以及利用错误处理机制展开攻击、等等。每种攻击都类似与 SQL 注入攻击,根据应用程序本身的漏洞,对系统进行破坏工作,例如:获取系统权限、获取机密信息、模拟合法用户等等。
综上所述,这些利用 Web 应用漏洞的攻击是 Web 安全最主要的威胁来源,75%的攻击来源于此,只有对应用程序本身进行改造才能避免攻击。然而,如何发现这些应用漏洞是保证安全的第一前提,我们如何以最快最有效的方式发现 Web 应用本身的漏洞呢?没有高效检测手段,安全的 Web 应用将成为水中花镜中月。
3 通过 Rational AppScan 如何应对网站攻击
IBM Rational AppScan 正是应对这一挑战的利器。
如下图所示,Rational AppScan 工作方式比较简单,就像一个黑盒测试工具一样,测试人员不需要了解 Web 应用本身的结构。AppScan 拥有庞大完整的攻击特征库,通过在 http request 中插入测试用例的方法实现几百中应用攻击,再通过分析 http response 判断该应用是否存在相应的漏洞。整个过程简单易懂高效,测试人员可以快速的定位漏洞所在的位置,同时 AppScan 可以详细指出该漏洞的原理以及解决该漏洞的方法,帮助开发人员迅速修复程序安全隐患。对于攻击的特征以及测试用例用户不需要花费大量的精力,WatchFire 团队定期的对特征库进行更新,随着保证与业界的同步,最大化的提高用户的工作效率。
图 4. Rational AppScan 工作示意图
下面我们通过简单的实例介绍一下 Rational AppScan 的使用:
定义扫描
首先确定扫描站点的 URL,根据默认的模板配置向导,确定扫描的整个站点模型以及你想扫描的漏洞种类。例如,我想扫描企业应用 www.xxx.com
,想根据默认值扫描是否有安全隐患,启动 AppScan,创建一个扫描,敲入 www.xxx.com
; 根据配置向导直至完成。
图 5. 默认的模板配置向导
图 6. 创建一个扫描
扫描启动,进行测试 只需要点击执行。
扫描结果查看
如图所示,AppScan 以各种维度展现了扫描后的结果,不仅仅定位了问题发生的位置,也提出了问题的解决方案。
图片看不清楚?请点击这里查看原图(大图)。
图 7. 扫描后的结果
4 Rational AppScan 深入介绍
Rational AppScan 同时提供了很多高级功能,帮助客户对复杂应用进行检测。支持的扫描配置有:
Starting URL:起始 URL,制定被测应用的起始地址
Custom Error Pages:制定错误网页提高测试效率
Session IDs:管理测试过程中的 session
Automatic Server Detection:自动检测应用所在的应用服务器、web server、操作系统
Exclusion and Inclusion:制定哪些 Web 被扫描或者被排除,哪些文件类型不被扫描
Scan Limits:其他高级扫描限制,例如扫描次数限制等
Advanced:扫描的方式,是宽度扫描还是深度扫描
Communication Settings:对扫描中的延时、线程数量进行配置
Proxy Settings:代理设置vLogin/logout:对被测应用的登陆进行设置,可以采用录制回放的方式、也可以使用自动登陆的方式
configure a Test Policy: 配置测试测量,即想测试哪些漏洞。
……
如上所述,用户可以通过 AppScan 进行一系列高级配置,制定所要检测的 Web 模型,即哪些需要扫描、哪些不需要、扫描的方式等等;也可以定义需要扫描漏洞的列表,从而保证了用户关心的网站模型有无用户所关心的安全漏洞。在检测出安全漏洞之后,AppScan 又提供了全面的解决方案帮助客户快速解决这些问题,最大化的保证 Web 应用的安全。另外,对于 Web 服务 AppScan 同样可以支持。
AppScan 提供了完善的报表功能,可以支持用户对扫描的结果进行各种分析,包括对行业或者法规的支持程度;同时,AppScan 也提供了一系列的小工具,例如:Authentication Tester 通过暴力检测方法扫描被测网站的用户名称和密码;HTTP Request Editor 提供了编辑 Http request 的功能,等等。
5 Rational AppScan 的使用场景
在整个软件开发生命周期中的各个阶段,Rational AppScan 都可以被使用,全面的保障了软件的安全性。如下图所示,软件开发过程中,软件开发人员、软件测试人员、QA、审核人员等诸多角色都可以通过 AppScan 检测应用,将漏洞尽早挖掘出来。下面我们通过一些使用场景介绍一下 AppScan 给软件开发带来的利益。
图 8. AppScan 使用场景
5.1 开发人员使用 AppScan
开发人员在开发过程中可以使用 AppScan 或者专用插件,随时开发随时测试,最大化的保证个人开发程序的安全性。越早发现问题,解决问题的成本就越低,这为 Web 应用的安全提供了最为坚实的基础保障。
测试人员使用 AppScan
系统测试人员使用 AppScan 对应用做全面的测试,一旦发现问题,可以快速的生成 defect,通过与 ClearQuest 的集成可以实现 defect 电子化跟踪,再传递到开发人员手中,指导开发人员迅速解决问题。极大的提高了开发团队的开发效率,也提供了完整了沟通平台解决方案。
5.3 审核人员上线前使用 AppScan
这是系统上线前的安全质量关卡。任何系统上线都应该经过严格的上线测试,这也最大化的减少了上线后问题的出现,避免生产系统上线后给企业带来的巨额损失。
5.4 上线后审计、监控人员使用 AppScan
上线的系统应该定期检测,一旦出现问题更应该及时检测,越快速的定位发现问题,损失就会越小。
上面我们介绍的是比较通用的使用场景。当然,不同的企业可能不同的特点,AppScan 使用场景的原则是最大化的提高使用效率、尽早的把问题暴露出来,为应用安全打下坚实的基础。每个企业都可以根据自身的开发现状定义适合自己的使用模式。
6. 为企业带来的收益
通过上面的介绍,我们对 Web 安全现状、应用安全重要性、以及应用安全产品 Rational AppScan 的使用有了一定的认识。但是,工具带给客户的不仅仅是一些功能,更为重要的是给企业带来的深层次的收益,给企业在开发过程、安全策略等层面带来了深刻的变化 . 下面我们从几方面阐述 AppScan 给企业带来的价值:
AppScan 是 Web 应用安全的坚实保障
正如上面所论述的一样,当前 Web 安全 75%的漏洞出自于应用本身,快速全面的定位问题并提供完善的解决方案将会帮助开发团队构建一个健壮的应用。
AppScan 使得开发成本降低、开发效率提高
开发测试人员通过 Rational AppScan 可以迅速的定位安全隐患,早期发现问题不仅有助于解决问题,更降低了开发成本,避免问题过晚出现所造成的巨大损失。
AppScan 给企业提供了统计分析能力
Rational AppScan 提供了灵活报表功能,可以支持对扫描结果进行统计分析;支持对规范法规遵循的分析;更提供了 Delta 比较报告,可以比较两次检测的结果从而作为质量检验的基础数据 AppScan 帮助建立企业级的测试策略库
Rational AppScan
帮助企业根据不同的应用类型建立不同的测试策略,同时用户可以定义针对不同威胁的解决方法,持续的知识积累保证了企业拥有更完善的安全解决方案。
总结
综上所述,随着 Internet 的蓬勃发展,Web 的安全性已经被空前重视,薄弱的安全性也成为了很多企业发展的瓶颈。然而,即便安全性如此受重视的今天,很多人对如何保障 Web 的安去性都存在着巨大的误区。现实表明,只有加强 Web 应用的防护,才能有效的防范 75%的攻击,Web 应用的防护已经成为安全话题中最为不可获缺的部分。IBM Rational 提供了 Rational AppScan 解决方案,在 Web 开发、测试、维护、运营的整个生命周期中,帮助企业高效的发现、解决安全漏洞,最大限度的保证了应用的安全性,为企业发展提供了坚实的技术保障。
原文来自:雨枫技术教程网 http://www.fengfly.com
原文网址:http://www.fengfly.com/plus/view-118735-1.html