使用Appscan保障Web应用安全性
编写：梁建增
http://www.cntester.com
Appscan简介
IBM Rational AppScan Standard Edition 是一种自动化 Web 应用程序安全性测试引擎，能够连续、自动地审查 Web 应用程序、测试安全性问题，并生成包含修订建议的行动报告，简化补救过程。
IBM Rational AppScan Standard Edition 提供：
Ø 核心漏洞支持：包含 WASC 隐患分类中已识别的漏洞——如 SQL 注入、跨站点脚本攻击和缓冲区溢出。
Ø 广泛的应用程序覆盖：包含集成 Web 服务扫描和 JavaScript 执行（包括 Ajax）与解析。
Ø 自定义和可扩展功能：AppScan eXtension Framework 运行用户社区共享和构建开源插件。
Ø 高级补救建议：展示全面的任务清单，用于修订扫描过程中揭示的问题。
Ø 面向渗透测试人员的自动化功能：高级测试实用工具和 Pyscan 框架作为手动测试的补充，提供更强大的力量和更高的效率。
法规遵从性报告：40 种开箱即用的遵从性报告，包括 PCI Data Security Standard、ISO 17799 和 ISO 27001 以及 Basel II。
1. 信息系统安全性概述
在进行软件安全性检测之前，首先我们应该具备一定的信息系统安全性的知识，在我们对整体范围的信息系统安全性保障有一定认识的前提下，才能决定我们能更好的保障该环境下的软件应用安全性。
计算机信息系统是由计算机及其相关的和配套的设备、设施（含网络）构成的，按照一定的应用目标和规则对信息进行采集、加工、存储、传输、检索等处理的人机系统。从而我们可以得知计算机信息系统的安全性是一个相当复杂且广的课题，通常情况下，计算机信息系统都是以应用性为主题，以实现不同用户群的相应需求实现。而应用性的实现通常是采用应用软件而达成。典型的计算机信息系统，包括了机房环境，主机设备，网络交换设备，传输通信媒介，软件系统以及其他相关硬软件，而由于当前信息系统网络的连通性，给安全性问题带来了更大的挑战。
在当今的时代，Internet（因特网）已经成为一个非常重要的基础平台，很多企业都将应用架设在该平台上，为客户提供更为方便、快捷的服务支持。这些应用在功能和性能上，都在不断的完善和提高，然而在非常重要的安全性上，却没有得到足够的重视。由于网络技术日趋成熟，黑客们也将注意力从以往对网络服务器的攻击逐步转移到了对 Web 应用的攻击上。根据 Gartner 的最新调查，信息安全攻击有 75% 都是发生在 Web 应用而非网络层面上。同时，数据也显示，三分之二的 Web 站点都相当脆弱，易受攻击。然而现实确是，绝大多数企业将大量的投资花费在网络和服务器的安全上，没有从真正意义上保证 Web 应用本身的安全，给黑客以可乘之机。
2. Web安全性测试要点
2.1. Web应用安全测试的重要性
由于我们将讲述的重点是AppScan，所以下面我们将主要对WEB应用的安全性在整个信息系统体系中的特点进行介绍。
通常，我们为客户提供的一系列解决方案中，WEB应用是属于自我研发的，该层次的安全性常常处于一种不被认知的状态中。并且由于应用系统的特殊性与针对性，商业化的安全保护产品很难考虑到这些特有的应用功能。所以，我们为客户实现的整个解决方案的信息系统环境中，无论客户采用了多么强大的防火墙，以及多么昂贵的IDS（入侵诊断系统）/IPS（入侵防御系统）等，但都无法防止对看似合法渠道的应用漏洞攻击，因为无论封闭的再怎么严实的信息系统都需要开发一些服务的端口以便能为合法用户提供服务，而攻击者就会通过从这些合法的入口中，寻找隐藏的应用系统漏洞，而通过应用系统漏洞的入侵，是其他安全保障软件以及硬件所难以察觉的，而这类窃取和破坏往往又是难以察觉和致命的。
为什么说一般的安全工具往往很难捕捉应用层次的安全问题呢？
Ø 网络脆弱性扫描工具，由于它仅仅用来分析网络层面的漏洞，不了解应用本身，所以不能彻底提高 Web 应用安全性；
Ø 防火墙可以阻止对重要端口的访问，但是提供服务的端口始终要开放，我们无法判断这些服务端口中通讯数据是善意的访问还是恶意的攻击；
Ø SSL 可以加密数据，但是它仅仅保护了在传输过程中数据的安全性，并没有保护 Web 应用本身；
Ø 阶段性的渗透测试，无法满足处于不断变更之中的应用。
2.2. Web 应用安全威胁
Web Application Security Consortium（WASC），是一个由安全专家、行业顾问和诸多组织的代表组成的国际团体。他们负责为 WWW 制定被广为接受的应用安全标准。WASC 组织的关键项目之一是“Web 安全威胁分类”，也就是将 Web 应用所受到的威胁、攻击进行说明并归纳成具有共同特征的分类。该项目的目的是针对 Web 应用的安全隐患，制定和推广行业标准术语。WASC 将 Web 应用安全威胁分为如下六类：
Ø Authentication（验证）用来确认某用户、服务或是应用身份的攻击手段。
Ø Authorization（授权） 用来决定是否某用户、服务或是应用具有执行请求动作必要权限的攻击手段。
Ø Client-Side Attacks（客户侧攻击） 用来扰乱或是探测 Web 站点用户的攻击手段。
Ø Command Execution（命令执行） 在 Web 站点上执行远程命令的攻击手段。
Ø Information Disclosure（信息暴露） 用来获取 Web 站点具体系统信息的攻击手段。
Ø Logical Attacks（逻辑性攻击） 用来扰乱或是探测 Web 应用逻辑流程的攻击手段。
2.3. 常见的Web应用攻击
Open Web Application Security Project（OWASP），该组织致力于发现和解决不安全 Web 应用的根本原因。它们最重要的项目之一是“Web 应用的十大安全隐患”，总结了目前 Web 应用最常受到的十种攻击手段，并且按照攻击发生的概率进行了排序。这个项目的目的是统一业界最关键的 Web 应用安全隐患，并且加强企业对 Web 应用安全的意识。
常见的 Web 应用攻击示例：
在 OWASP 组织列举的十大Web 应用安全隐患中，有两个概率最高的攻击手段，它们分别是“跨站点脚本攻击”（Cross-Site Scripting）和“注入缺陷”（Injection Flaws）。下面将通过举例来说明这两种攻击是如何实施的。
Ø 跨站点脚本攻击
恶意攻击者（这里使用 Evil.org 表示）通过 E-mail 或 HTTP 将某银行的网址链接发给用户（银行用 bank.com 表示），该链接中附加了恶意的脚本（上图步骤一）；用户访问发来的链接，进入银行网站，同时，嵌在链接中的脚本被用户的浏览器执行（上图步骤二、三）；用户在银行网站的所有操作，包括用户的 cookie 和 session 信息，都被脚本收集到，并且在用户毫不知情的情况下发送给恶意攻击者（上图步骤四）；恶意攻击者使用偷来的 session 信息，伪装成该用户，进入银行网站，进行非法活动（上图步骤五）。
因此，只要 Web 应用中，有可被恶意攻击者利用执行脚本的地方，都存在极大的安全隐患。黑客们如果可以让用户执行他们提供的脚本，就可以从用户正在浏览的域中偷到他的个人信息、可以完全修改用户看到的页面内容、跟踪用户在浏览器中的每一个动作，甚至利用用户浏览器的缺陷完全控制用户的机器。
目前，跨站点脚本攻击是最大的安全风险。
Ø 注入缺陷
目前的 Web 应用中，绝大多数都会向用户提供一个接口，用来进行权限验证、搜索、查询信息等功能。比如一个在线银行应用，首先会有对注册客户进行身份验证的登录界面，在正确登录后，会提供更多交互功能，如根据客户的银行卡号信息，查询客户的最近交易、转账细节等。这些都是注入缺陷的最佳利用场景。所谓注入缺陷，就是在上述场景中，用户输入的数据被当做命令和查询的一部分，送到后端的解释器中解释执行。如果用户的输入是正常合法的，Web 应用自然会返回正常合理的结果，但是，如果恶意攻击者，利用输入数据可被后台执行的原理，偷梁换柱，使用非法的输入，脆弱的 Web 应用会怎样呢？
下面我们举一个例子来说明注入缺陷是如何进行的。在一个交易网站中，用户必须输入产品 ID 号才可以查看该产品的详细信息。为了实现这个需求，通常会用 SQL 语句查询数据库来实现。开发人员在编写应用程序时，可能会使用如下的 SQL 语句来实现上述目的（这里仅为示例）：
1) Select * from products where product_id = ` + 用户输入的 ID + `
这里的 products 是数据库中用来存放产品信息的表，＋号表示 SQL 语句需要和用户输入的真实 ID 进行拼接。如果用户输入 325，则该语句在执行时变为：
Select * from products where product_id = ` 325 `
数据库会将 ID 为 325 的产品信息返回给用户。
2) 在界面上，需要用户输入产品 ID 的地方，黑客会输入如下数据：
` or `1`= `1
可以看到，黑客并没有输入正常合法的产品编号。
3) 通过黑客的非法输入，需要执行的 SQL 语句变为：
Select * from products where product_id = ` ` or `1`=`1`
可以看出，SQL 语句的意义就完全改变了，当产品 ID 为空或者 1＝1 时，返回产品所有信息，而 1＝1 是永远成立的条件，因此，黑客并没有输入任何产品编号，就可以返回数据库中所有产品的详细信息。
通过这个例子，我们可以看出，注入缺陷是风险非常高的安全漏洞，一旦 Web 应用中给用户提供了需要其输入数据的接口，就有可能遭到攻击，将后台的数据完全暴露在用户的面前。
上述说明的“跨站点脚本攻击”和“注入缺陷攻击”，是目前 Web 应用中比例最高的两种攻击手段，按照 OWASP 的项目排序，还有如下八种风险性较高的攻击方法：
Ø Malicious File Execution（恶意文件执行）；
Ø Insecure Direct Object Reference（不安全的直接对象引用）；
Ø Cross-Site Request Forgery（跨站点的请求伪造）；
Ø Information Leakage and Improper Error Handling（信息泄漏和不正确的错误处理）；
Ø Broken Authentication & Session Management（损坏的认证和 Session 管理）；
Ø Insecure Cryptographic Storage（不安全的密码存储）；
Ø Insecure Communications（不安全的通信）；
Ø Failure to Restrict URL Access（未能限制 URL 访问）
2.4.
3. 如何保障Web应用安全性
如何构建安全的Web应用系统，这不仅仅是软件测试人员对应用系统进行安全检测通过后所能保证的。
有一定安全保证的Web应用系统，应是从系统的需求分析和设计阶段开始着手考虑，系统的安全性需求应被纳入需求中，且应描述在较为明确的范围内；在系统的设计阶段，应准确的将安全性的需求转化为安全性保证的设计，从设计的角度考量不同的安全技术对于系统安全的保证所达到的预期层度，并不能因为单纯的加入登陆的身份验证功能而能保障系统对身份鉴别的安全性，系统的安全保证设计应从较为全面的角度入手，遵守安全设计原则。
同时，到了开发阶段，对安全设计的实现也需要遵从安全性编码的规范，如SQL注入攻击，并非需求设计上没有加入身份验证功能，而是由于该功能的实现存在了攻击漏洞，这是因为在编码实现时没有遵从安全性编码的规范。
在测试阶段，测试人员不仅仅要对安全的需求设计进行确认，确保安全保证模块的功能正确性，还应引入较成熟的软件安全性自动化扫描工具，对系统的实体进行全面的扫描，通过自动化工具大量成熟的测试策略以及自动生成的大量测试用例，去检测应用系统中的安全隐患。
4. Appscan概要
4.1. 扫描原理
4.1.1. 探测阶段
在这个阶段，Appscan主要的工作是模仿一个用户对被访问的Web应用或Web服务站点进行探测访问，它这时主要工作是通过发送请求对站点内的链接与表单域进行访问或填写，以获取相应的站点信息。之后，Appscan分析器将会对自己发送的每一个请求后的响应做出判断，然后查找出任何可能潜在风险的地方，并针对这些可能会隐含风险的响应，确定将要自动生成的测试用例。对于探测过程中，所采用的测试策略可以选择默认的或自定义的，可采用不同的测试策略，测试策略库是Appscan内置的，它可以定义为你想要的组合，去检测你最想检测的可能存在的安全隐患。
Appscan测试策略库是针对WASC和OWASP这两大安全组织所认为的安全风险定置的。并且，测试策略库就如同病毒库一般，时刻保持着最新的状态，可以通过对策略库的更新，来检测最近发现的Web漏洞。
探测阶段完成后，这些高危区域是否真的隐含着安全缺陷或应做更好的改良，以及这些隐含的风险是处于什么层度的，是需要在测试执行完成后，才能最终得出决论。
4.1.2. 测试阶段
测试阶段其实同探测阶段是处于同一个过程的，现在区分开来，主要是让我们更了解Appscan的共作流程。继上一个探测阶段后，Appscan已经分析出可能潜在安全风险的站点模型。也已经知道需要生成多少的测试用例，以便检测这些区域的安全隐患。这个时候的工作，主要就是生成这些已经计划好的测试用例。Appscan是通过测试策略库中对相应安全隐患的检测规则而生成对应的测试输入，这些足够全面而且复杂的测试输入，将会在扫描执行阶段对系统进行验证，通过这些全面合理的测试输入数据，我们就可以想象这是我们人工执行所难以达到的。通常对一个系统的测试，将会生成上万甚至几十万上百万的测试用例输入。
4.1.3. 扫描阶段
在这个阶段，Appscan才是真正的工作起来，他将会把上个阶段的测试用例产生的服务请求陆续的发送出去，然后再检测分析服务的响应结果，从而判断该测试用例的输入，是否造成了安全隐患或安全问题，然后再通过测试用例生成的策略，找出该安全问题的描述，以及该问题的解决方案，同时还报告相关参数的请求发送以及响应结果。
扫描阶段完成以后，Appscan中将统计相应的安全问题的检测结果，可以再进行检测结果的报告导出等，继而对检测出的问题进行逐个的分析，并可依据报告对问题进行修复或改良。
4.2. 典型工作流
Appscan是一个交互式的工具，他测试的范围和层度取决于你对它进行的相应配置，因此，在使Appscan为我们工作之前，我们应先对它进行相应的配置，以满足我们不同范围和层度的需求。当然，你也可以通过默认的内置定义进行测试，那么Appscan将会按照它缺省的设置进行测试。通常情况下Appscan包含下面的操作流程。
4.2.1. Template Selection（模板选择）
你可以预先定义一套模板，或则选择系统默认的设置模板。预定义模板可以通过先选择默认模板后，完成向导后先暂时不执行测试，然后再对当前的扫描任务进行自定义，定义为你想要的模板样式，然后在Scan Configuration中选择另存，保存为你想要的模板，之后再创建新的扫描时，就可以选择这个定义好的扫描模板。
4.2.2. Application or Web Service Scan（应用或Web服务扫描）
你需要选择你测试的对象是Web应用程序还是Web服务。
4.2.3. Scan Configuration（扫描配置）
在这进行扫描配置，你需要设置你要访问的应用或服务，然后设置登陆验证，之后将对你所需要采用的测试策略进行选择，可以使用默认的配置或加载修改适合你需要的配置。
4.2.4. Scan the Application or Service（扫描应用或服务）
这里的工作包括了探测和测试阶段。
Ø Explore（探测）：在探测阶段里，Appscan将会爬行访问你的站点，他会按照你制定的规则访问链接并记录访问后的响应，然后创建出包括URL、目录、文件等等的层次结构，而这些结构将展示在一个Application Tree（应用树）里。你可以通过自动或手动浏览的方式来完成这个探测过程，你还可以通过导入已经录制好的手工浏览脚本文件来实现你想要的探测方式。
Ø Test（测试）：在测试阶段里，Appscan会依据有关的规则，访问探测阶段发现的相应URL、输入参数以及输出响应，这些测试用例都是采用先进的技术来发现这其中存在的安全隐患。Appscan自动生成不同的测试用例，这些测试用例主要包括以下两种类型
n Infrastructure Tests（异常结构测试）：这类测试主要是测试已知的安全隐患，主要包括商业化的工具、第三方产品插件、IE浏览器等中存在的安全性脆弱的部分。
n Application Tests（应用测试）：这类测试将测试你系统中特有的应用，Appscan将会通过复杂的智能算法来学习当前系统中的应用逻辑，并生成这类有效的应用测试。
这些测试用例可以通过更改测试策略中的组合以及配置来达成你想要的测试效果，这些测试策略都是Appscan根据业界与WASC和OWASP两大安全组织等声明的潜在安全攻击隐患而针对定置的检测策略。但如果你觉得不足够，你也可以进行自定义测试策略，用来实现你特有的想法或需求，假如你觉得这很有必要并且你会的话。
Ø Review Results（回归结果集）：如果你觉得有需要，可以再次回归检测后的结果集，然后手工追加你仍要探测的链接，以及回归一下需要进行补救修复的任务。
4.2.5. Appscan窗口介绍
Appscan从界面上看，操作对象不是很多，并不复杂，主要由以下几个部分组成。
4.2.5.1. 菜单
Ø File Menu（文件菜单）：进行创建、打开和保存扫描。
Ø （Edit Menu）编辑菜单：提供定制扫描结果功能
Ø （View Menu）视图菜单：让你决定主窗口的数据如何显示
Ø (Scan menu)扫描菜单：用来控制扫描
Ø 1
Ø 2
Ø 3
4.2.5.2. 工具栏
The buttons of the toolbar offer quick access to common features also available from the menus.
新建 打开 保存 打印 扫描 停止 手工探测 设置
4.2.5.3. 视图选择
4.2.5.4. 应用树
4.2.5.5. 结果清单
4.2.5.6. 详细窗格
4.2.5.7. 扫描面板
4.2.5.8. 状态条
4.2.6. 的
5. 扫描设置
5.1. 扫描配置概要
一个完整的扫描过程包括探测和测试一个应用，然后将结果呈现在窗体中。下面展示了一般情况下扫描流程的配置过程。
5.2. 管理扫描模板
当你配置好一个扫描后，你可以将它另存外一个扫描模板，在这之后的测试中你都可以采用这个扫描模板来进行测试。你可以在进行测试前或则测试完成后来创建这个模板。
同时，如果你有一个很有趣的结果需要让开发员或则QA都看看的话，有需要重新运行一回测试，你也可以另存这个模板然后再运行时加载后使用就可以省去大量的配置时间。
创建和保存一个扫描模板的过程：
1） 通过Scan Configuration Wizard（扫描配置向导）来配置扫描；或则是通过Scan Configuration（扫描配置）来实现；或则是打开一个你想要另存模板的现有扫描文件。
2） 在File menu（文件菜单）里点击Save As（另存）。
3） 在Save As（另存）对话框里选择 .scant 文件类型，然后输入文件名，点击Save（保存）。
5.3. 扫描配置向导
5.4. 的
6. 扫描流程
6.1. 扫描概要
一个完整的扫描，包括了探测阶段和测试阶段。当扫描开始后，进度条会显示在结果清单的面板内。进度条面板内会显示以下的信息：
Ø 当前处于探测或则测试中的URL。
Ø 测试阶段完成的百分比。
Ø 如果是之后的测试阶段，则会显示阶段号（如果是多阶段扫描的话）
Ø 执行到当前的时间数值
如果扫描停止，或则当网络通信或则出现请求故障时，进度条下的Scan Notice Panel（扫描注意面板）将会显示扫描停止的原因和信息，信息内容如下：
Ø Communication issues and timeout before automatic resume.
Ø Notification that scan is incomplete.
Ø Link to more information, which opens a dialog box explaining what has been done so far and how to continue.
6.2. 开始扫描
如果是使用Scan Configuration Wizard （扫描配置向导）来创建你的扫描，向导的最后一步将会提供开始执行扫描的选择项。
如何开始执行一个扫描：
6.3. 停止与继续扫描
你可以停止或重新继续一个扫描，在工具栏的
6.4. 保存与加载扫描
6.5. 自动扫描
6.5.1. 探测阶段
这个阶段Appscan将会按照用户的设置，从在向导中配置的起始URL上开始爬行应用程序的每一个URL，除了那些已经设置为排除在外的。同时将为应用的URL构建一个层次分明的Application Tree（应用树）模型。最后Appscan将会对探测URL进行分析和生成测试用例。
6.5.2. 测试阶段
在这个阶段，Appscan将会登陆应用，然后Performs preliminary tests on the URLs, which help interpret results
6.5.3. 自动多阶段扫描
6.6. 手动探测
6.7. 导出扫描结果
7. 结果分析
7.1. A
7.2. B
8. 结果报告
8.1. A
8.2. B
9. 附带工具
9.1. A
9.2. B
10. 问题指南
10.1. A
10.2. B