深入探析 Rational AppScan Standard Edition 新特性之 Glass Box 扫描

众所周知，Web 应用安全测试通常有黑盒安全测试和白盒安全测试两种方法。这两种方法孰优孰劣一直众议纷纷。广为公认的是，这两种测试方法有着良好地互补性，两种测试方法的结合是未来安全测试技术的发展趋势。Glass Box 是 IBM 发布的一项领先混合测试技术，它增强了 Rational AppScan Standard Edition 的探索能力，提高了扫描效率和结果准确性。本文将跟读者分享这项新技术，帮助读者掌握在实际项目中应用 Glass Box 扫描。

常见安全测试技术

Web 应用的自动化安全测试技术一般分为两类：黑盒安全测试和白盒安全测试。这两种方法孰优孰劣一直众口不一。广为公认的是，这两种方式各有优缺点，且具有良好的互补性。下面笔者简单介绍一下两种测试技术的原理，便于读者了解这两种技术的优缺点。

白盒安全测试技术

白盒安全测试有时候也被称为静态测试，主要基于源代码进行分析。因此，白盒安全测试不需要部署、运行整个应用。白盒安全测试主要分析代码中的函数及其调用关系，分析数据在其中的不同的执行路径。常见白盒安全测试工具主要采用污染分析（Taint Analysis）方法，它检测代码中所有可能的数据流，寻找黑客可以利用的输入数据，跟踪这些数据在整个应用中的使用过程，以及最终的数据去向，结合规则来判断当前数据流是否存在安全漏洞。例如，如果某个输入字段通过 HTTP 请求传入系统中，最终被编织到某个数据库查询语句被执行，白盒安全检测工具就能根据这个数据流分析出可能存在 SQL 注入漏洞。白盒安全测试的优势很明显，它通常能检查整个应用中的所有代码，分析代码中的所有执行路径，精确定位到具体代码行存在的安全漏洞。但它的缺点也比较多，譬如：

基于白盒安全测试的原理，它能检测应用中代码的所有执行路径和数据流。但事实总跟理论有些差距，实际项目中白盒安全测试并不能真正做到这一点。譬如：如果代码中采取了反射机制，白盒安全就难以处理这类逻辑；如果代码中存在大量多线程并发，白盒安全测试也难以检测这些并发问题；此外，如果应用的控制流是基于配置文件实现的，譬如基于 Spring 配置，白盒安全测试工具也难以分析这类框架下完整的数据流。
白盒安全测试仅侧重代码的分析，而不考虑中间件部署等问题。测试过程不依赖运行环境虽然简化了安全测试方法，但是存在很多基础中间件层的安全漏洞，白盒安全测试技术无法检测此类问题，可以说这是白盒安全测试先天性的不足。
白盒安全测试引以为傲的一点是，它能测试代码中的所有执行路径。这其实是一把双刃剑。实际项目运行过程中，实际会执行到的路径跟理论存在的路径相比，会远远小于理论路径数量。读者可以找些代码进行度量分析，某些方法圈复杂度可能会 30 以上，但实际我们不一定为它写那么多单元测试用例，我们的单元测试用例往往只会覆盖到实际项目可能会命中的那些路径。因此，白盒安全测试工具往往会检测出大量的安全漏洞，其中大量问题事实上在运行期永远不会被执行到。

黑盒安全测试技术

黑盒安全测试有时候也被称为动态测试。这种方法主要测试应用的功能点，而不是分析内部代码。黑盒安全不需要测试人员具备编程能力，不需要测试人员了解代码实现的逻辑，因此常常是业界安全测试人员的首选安全测试方法。黑盒安全测试过程中，往往通过网页爬虫模拟正常用户访问应用站点，探测出应用站点的全部访问路径，然后基于探测结果生成安全测试用例。黑盒测试工具会分析安全测试用例触发的 HTTP 响应，判断其中是否存在某种安全漏洞。由此看出，黑盒测试时，被测站点往往被视为一个黑盒，我们不用去关心它如何运行，用何种语言编写。黑盒测试技术从用户的角度，或者说是从黑客的角度去分析测试站点，它所发现的问题往往更为精确，同时也能检测出中间件配置问题所导致的安全漏洞。黑盒安全测试同样也存在着一些不足。

测试覆盖率较低。由于黑盒安全测试是从用户角度分析站点的 URL，而不是从源代码级分析方法的参数，因此，黑盒测试的测试覆盖率会小于白盒安全测试。对于黑盒安全测试工具而言，以下场景都很难自动探测出来。譬如：根据特定表单字段内容控制的不同页面逻辑；某个请求存在隐式的参数（即某些参数没公开，通过 URL 发现不到这些参数）等。
黑盒安全测试无法发现某些安全漏洞。由于黑盒安全测试本质上基于服务器端的响应来验证漏洞是否存在。大多数安全漏洞可以通过这种方式分析出来，但不是所有漏洞都能如此。譬如：密码以明文存储，这种安全隐患就不能通过黑盒测试检测出来；系统存在默认调试密码的现象也无法通过黑盒测试检测出来。由此可见，只要被污染参数没有被写回 HTTP 响应，黑盒安全测试技术就无法探测出相应的漏洞。
黑盒安全测试所发现的安全漏洞修复难度大。尽管黑盒安全测试所发现的安全漏洞容易被重现，但根据 HTTP 请求 / 响应找出存在安全漏洞的代码行并不是一件容易的事情。相信从事过相关安全漏洞修复的读者对此都感受深刻。
黑盒安全测试效率较低。根据黑盒安全测试原理可以知道，黑盒测试工具往往会根据所探测出来的 URL 设计安全测试用例（也称为测试变体），譬如一个 URL 中存在三个参数，黑盒测试工具会为每个参数都设计大量的测试变体，如 XSS 变体、注入变体等等。随着已知漏洞数量的增加，需要设计的测试变体会越来越多。这样对于一个 URL 的测试变体往往会有好几十个，甚至上百个。这种测试方法不仅仅会对被测试站点带来较高的访问压力，对于测试机器而言，也会因多线程发送大量请求、分析大量响应导致测试性能低下。尤其对于一个大型站点来说，黑盒安全测试的性能往往比较低下，需要针对性的进行扫描性能调优。

由此可见，黑盒安全测试和白盒安全测试两种方法各具特色和不足，且两者具备较好的互补性。目前业界基本公认，两者的结合（即混合测试，Hybrid Test）是下一代安全检测技术的发展趋势。AppScan Standard v8.5（下文简称 AppScan）新发布了 Glass Box 安全测试技术（下文称之为"玻璃盒测试技术"），创新地在黑盒安全测试工具中引入了代码分析技术，实现了混合测试。下文笔者将跟读者分析这一新技术，探究它的运行原理，帮助读者掌握并运用到实际项目中去。

新一代玻璃盒安全测试技术

近年来 IBM 安全团队一直致力于研究开发新一代安全检测技术，即玻璃盒安全测试技术，并在 2009 年为之申请了专利。简言之，利用玻璃盒测试技术，测试工具可以在做黑盒测试的同时，观察并分析服务器端运行期所执行的代码。研究发现，这种新方法改进了传统黑盒测试的不足。图 1 展示了玻璃盒测试技术的基本原理，下文将详细介绍玻璃盒安全测试技术是如何综合黑白盒两种技术之长。

图 1. 玻璃盒测试原理图

我们可以看到，跟以前版本的 AppScan 相比，这里多了两个组件：玻璃盒代理（Glass Box Agent）和玻璃盒引擎（Glass Box Engine）。玻璃盒代理是用来采集信息的应用程序，负责监控、收集和分析所在组件中的有价值信息，然后将这些信息发送给 AppScan，AppScan 会基于这些信息改进探索和测试。根据 IBM 发布的玻璃盒技术白皮书，玻璃盒代理通常可以部署在 Web 应用环境中的不同组件中，譬如 Web 应用服务器、操作系统或者数据库。不同环境中的玻璃盒代理所收集的信息不同。表 1 阐述了不同位置的玻璃盒代理所采集的不同信息，以及这些信息会如何改进测试结果。

表 1. 常见玻璃盒代理

代理所在位置	所采集信息	改善点
代理所在位置	所采集信息	精确度	性能	漏洞报告
Web 应用	运行期代码信息	√	√
Web 应用	源代码信息			√
Web 应用服务器	配置文件	√	√	√
Web 应用服务器	Web 服务器日志	√		√
操作系统	文件创建	√
	进程信息	√
	注册表访问	√
数据库服务器	SQL 执行信息	√	√

我们以表 1 中最后的数据库端的玻璃盒代理为例。Web 应用通常使用外部的关系型数据库来存储信息。通过在数据库端安装玻璃盒代理，黑盒测试工具即可监控到 Web 应用所执行的 SQL 语句。当黑盒测试工具发送一个 SQL 注入测试变体的时候，玻璃盒代理会分析数据库端实际执行的 SQL 语句，以此判断当前攻击是否成功。如果玻璃盒代理探测到攻击已经成功，它将通知黑盒测试工具，黑盒测试工具从而会报告存在 SQL 注入安全漏洞。请注意，这种判断方法跟基于 HTTP 响应对比的优势：如果 SQL 执行结果没有被回写到 HTTP 响应中，传统上的基于 HTTP 响应分析的方法就不能检测出当前存在 SQL 注入漏洞，而玻璃盒测试方法可以测试成功。此外，玻璃盒代理通过监控数据库端执行的 SQL 语句，可以知道当前 SQL 存在哪些参数，从而通知黑盒测试工具仅对这些参数发送 SQL 注入测试变体。这样就大大降低了无效测试变体的数量，从而提升了整体扫描效率。

AppScan v8.5 目前集成的的玻璃盒代理是运行期代码代理。这种代理可以在 Web 应用程序启动加载的时候，通过动态代理一类的机制，将监控代码动态注入到 Web 应用程序代码中。这样运行期代码代理可以监控到 Web 应用代码的执行情况，分析出代码的逻辑关系和运行期的数据流，从而找到数据的源和接收器。通过运行期代码代理，可以轻松定位安全漏洞所在代码，而且利用数据的源和接收器分析，安全漏洞的判定也比较容易和准确。

以上对玻璃盒代理的分析，从原理上解释了玻璃盒测试如何克服了传统黑盒测试工具和白盒测试工具的常见不足。下面我们总结一下玻璃盒技术的优势所在。

增强了探索能力

在黑盒测试工具的探测阶段，玻璃盒代理能够基于白盒分析找出应用中的隐藏参数，通知黑盒测试工具对隐藏参数进行探测。这种方式改善了黑盒测试工具的测试覆盖率。我们通过一个简单的例子来说明，参见清单 1 中的代码。

清单 1. 影响测试覆盖率的隐藏参数

String debug = request.getParameter("debug");

if(debug == "enabled"){

	// hidden code

}

如果黑盒测试工具没有发送 debug 参数为 enabled 的请求，这段隐藏代码就永远不会被测试到，黑盒测试工具也就无法检测这段代码是否存在安全漏洞，这就影响了测试覆盖率。玻璃盒测试技术通过玻璃盒代理找到这些代码分支，并查明这些代码分支的调用方式。玻璃盒代理会通知黑盒测试工具，后者会利用类似例中 debug 参数，发送测试变体去检测这段代码。

增强了测试能力

利用玻璃盒测试技术，黑盒测试工具可以准确知道操作系统、应用服务器、数据库及相关第三方组件等信息，从而改进测试策略的针对性，提高了测试精确性和测试效率。同时，通过玻璃盒代理监控服务器端环境，黑盒测试工具能够更好地验证安全漏洞是否存在。譬如那些不回写 HTTP 响应的安全漏洞，如日志伪造、不安全的加密存储及不合理的文件操作权限等。此外，玻璃盒技术也有利于提高安全漏洞报告的准确度，准确提示用户漏洞所在的文件名、方法名及代码行数等。

提升了效率和准确度

使用过黑盒测试工具的读者都知道，安全测试的时候经常需要权衡性能和准确度这两个指标。为了提高准确度，就需要增加测试变体数量，这就影响了测试性能；通过算法优化减少测试变体，还是会可能降低测试准确度。由于玻璃盒测试技术洞悉服务器端的环境和代码，利用这些信息，黑盒测试工具可以精确针对测试环境编制测试变体，这样的话，测试变体的数量会大大降低，而其测试覆盖率也不会受影响，所以能够保证测试准确度的同时，提高了测试效率。

IBM 研究人员曾对 WAVSEP（Web Application Vulnerability Scanner Evaluation Project）应用进行了对比测试，利用黑盒测试技术仅能测试出 62 个安全漏洞，而启用了玻璃盒测试技术后，AppScan 能测试出该网站的全部 198 个安全漏洞。这些数据进一步验证了玻璃盒测试技术的先进性。

掌握玻璃盒测试技术

在 AppScan 中启用玻璃盒测试非常简单，概括下来有三个步骤：

在应用服务器上安装玻璃盒测试代理程序，此操作仅需执行一次。虽然玻璃盒代理程序可以被安装到多台服务器上，但一次扫描过程中只能包含一台服务器。
在 AppScan 中定义已安装好的代理程序，以便它能与这些代理程序进行通信。同一个玻璃盒代理程序可以被多个 AppScan 使用，但不能同时使用。
配置扫描时启用所需的玻璃盒代理程序。缺省情况下这是自动配置的，可以在"扫描配置"-"Glass Box 视图"中为每个扫描调整代理程序配置。

另外，需要注意的是，如果 AppScan 自动更新的时候，若提示更新服务器代理程序，请务必执行该操作，以便 AppScan 和玻璃盒代理程序中的规则保持同步。同时，一旦玻璃盒代理程序完成更新，要重新启动 Web 应用服务器，重新加载服务器应用程序。

安装玻璃盒代理程序

目前版本的玻璃代理程序主要支持主流 Java EE 应用程序服务器（如 JBoss，Tomcat，WebLogic 和 WebSphere）。玻璃盒代理程序可以自动化安装，但考虑到 Java EE 应用服务器的配置通常较为复杂，为支持客户手工部署需求，玻璃盒代理程序也可以手动安装。AppScan 的用户手册中有详细的解释和示例。简而言之，玻璃盒代理程序安装主要包括 Java 代理程序包的配置和代理应用 WAR 包文件的部署。下面笔者在本机 Tomcat 环境中自动安装玻璃盒代理程序。

打开文件夹"C:\Program Files (x86)\IBM\Rational AppScan\Glass box"，双击 GB_Setup.exe 程序启动安装。（因为笔者是在本地安装，所以直接执行这个安装程序。如果应用服务器不在本机，则需要将这个文件夹的内容拷贝到应用服务器所在电脑上，确保文件访问权限正常后，再执行这个文件。）

图 2. 选择应用服务器

选择 Apache Tomcat 后，点击"下一步"，安装程序会提示指定 Tomcat 所在路径，譬如"D:\apache-tomcat-6.0.32"，然后点击"下一步"。

安装程序提示设置代理程序凭证，这里的用户名和密码将来需要记录到 AppScan 中，AppScan 利用这个帐号跟代理程序进行通信。

图 3. 设置代理程序的访问帐号

最后确认安装文件夹位置，点击"安装"完成代理程序的安装。安装程序会帮助你验证代理程序是否安装成功。我们也可以手工通过浏览器来验证：在浏览器中输入"http://localhost/GBootStrap/ "（读者需根据本机 Tomcat 的配置修改机器名和端口），如果系统提示输入密码，则输入步骤三提供的帐号，查看到"Glass Box API"的话，即说明安装成功。

注册玻璃盒代理程序

点击菜单"工具"-"Glass Box 代理程序管理"，打开管理界面，点击"+"按钮，注册刚才安装的玻璃盒代理程序，如图 4 所示。然后点击"确定"关闭对话框即可。

图 4. 注册玻璃盒代理程序

启用玻璃盒代理程序

当扫描某个应用服务器上的 Web 站点时，我们可以在扫描配置中启用安装在这台应用服务器上的玻璃盒代理程序。缺省情况下，AppScan 会自动启用目标应用服务器上已注册好的代理程序。在"扫描配置"对话框中，选择"探索 -Glass Box"即可看到配置项，如图 5 所示。

图 5. 启用玻璃盒代理程序

回页首

案例

下文笔者将针对本地的一个应用使用 AppScan 进行两次扫描，两次测试都扫描相同的站点，第一次不启用玻璃盒扫描，第二次启用玻璃盒扫描，其他配置完全相同。我们来看看两次扫描结果的区别。

首先笔者使用 AppScan 测试本地的 wavsep 程序：

点击"文件"-"新建"，使用"常规扫描"模板，设置"Web 应用程序扫描"。起始 URL 设置为"http://localhost/wavsep/index-active.jsp"，登录方法选择"无"，使用"开发者精要"测试策略。
因为 AppScan 默认会启用玻璃盒代理，这里笔者暂将之停用。点击"完全扫描配置"，在"Glass Box"选项中，禁用"在探索阶段使用 Glass Box"和"在测试阶段使用 Glass Box"。点击确定，启动全面自动扫描。
扫描完成后观察状态栏，我们可以看到已访问的 URL 是 315 个。测试共发现 66 个安全问题，如图 6 所示。

图 6. 停用玻璃盒测试的扫描结果

接下来，笔者启用玻璃盒代理，然后点击"扫描"-"重新扫描（全面）"，利用玻璃盒测试重新扫描上述站点。结果如图 7 所示。启用玻璃盒测试后，AppScan 探索出 398 个 URL，测试发现 70 个安全问题。由此可见，启用玻璃盒扫描后，AppScan 的探测能力增强，发现了更多的安全问题。

图 7. 启用玻璃盒测试的扫描结果

回页首

总结

玻璃盒测试技术是 IBM 发布的一项领先混合测试技术，它综合了黑盒安全测试和白盒安全测试的两者之长，克服了传统黑盒安全测试的不足，增强了 AppScan Standard 的探索能力，提高了扫描效率和结果准确性。本文笔者跟读者分享了玻璃盒测试技术的原理，介绍了 AppScan 中玻璃盒测试的使用方法，同时结合案例，跟读者演示了停用玻璃盒测试和启用玻璃盒测试两种场景下的测试结果，通过这两个测试结果的对比，让读者更直观领略到玻璃盒测试技术的领先。鉴于笔者经验有限，若有不及之处，欢迎读者来信交流。

参考资料

学习

查看文章"Web 应用安全利器：IBM Rational AppScan"，了解 Rational AppScan Standard 的基本使用。
>查看 IBM 白皮书"Glass box testing: Thinking inside the box"，了解 IBM 玻璃盒测试技术的研究成果。
参考 Rational AppScan产品专题，查看 IBM Rational AppScan 产品介绍及文档库。
参考 IBM X-Force 网站，了解 IBM 发布的最新因特网威胁趋势及应对威胁的建议。
参考WAVSEP 网站，了解 Web 应用安全漏洞扫描工具评估项目。
访问 IBM developerWorks 中国网站 Rational 专区，获得关于 IBM Rational 软件交付平台（Rational Software Delivery Platform）产品的技术资源和最佳实践。
订阅 IBM developerWorks 时事通讯，一份关于 developerWorks 指南、文章、下载、社区活动、网络广播和技术讲座的电子周刊。

获得产品和技术

下载免费的 IBM Rational AppScan Standard Edition（标准版）试用版。
获取免费的 Rational 软件工具包系列，了解最新的 IBM Rational 软件开发工具技术文档和资源。
下载更多免费的 IBM Rational 试用版软件，了解 IBM Rational 软件的最新特性。
获取更多 IBM 试用版软件，并熟练掌握来自 DB2®、Lotus®、Tivoli®，以及 WebSphere® 的开发工具和中间件产品，用这些试用版软件开发您的下一个项目。这些试用版软件可以免费直接从 developerWorks 下载。