基于 Web 的应用正受到越来越多的青睐，从企业应用到形形×××的公共站点，可以说 Web 无处不在。黑客也逐渐将注意力从以往对网络服务器的攻击逐步转移到了对 Web 应用的攻击上，“跨站脚本”、“SQL 注入”新的网络安全问题不断涌现，如何保障 Web 应用的安全已成为当今业界关注的问题。Rational AppScan 是 IBM 公司推出的全面 Web 安全解决方案，提供了扫描、报告和修复建议等功能，可以帮助开发者在项目起始阶段即全面准确地发现并解决安全问题。
Web 应用安全现状
很多开发人员对 Web 安全有着片面的认识，认为只要建立了防火墙，设置了入侵检测系统，部署了网络安全工具，Web 应用的安全就可以高枕无忧了。的确，通过以上措施确实可以从网络以及系统层面增强 Web 应用的安全性，但它片面强调了硬件的作用却忽视了 Web 应用本身的安全问题。对于存在缺陷的应用来说，再多的防护措施也将形同虚设。Web 安全是各种因素的综合体，涵盖了网络、操作系统、应用服务器以及 Web 应用本身的安全问题，任何方面的缺失都会将应用暴露于黑客的攻击之下。著名统计机构Gartner的报告称发生在网络上的攻击当中，大约 75% 是针对 Web 应用的；而另外一项统计数据更是让人不安，约 67% 的 Web 程序是存在安全缺陷的。
开放 Web 应用安全组织 OWASP（Open Web Application Security Project）发布了2010年 Web 应用十大安全缺陷，与上一榜单相比：注入缺陷（Injection flaws）位列榜首，跨站脚本攻击（Cross Site Scripting）退至第二；错误安全配置（Security Misconfiguration）与非法链接跳转（Unvalidated Redirects and Forwards）首次上榜，分列第六，第八位；恶意文件执行（Malicious File Execution）与信息泄露/异常处理（Imformation Leakage and Improper Error Handling）跌出前十。
为使读者对 Web 安全问题有所了解，在此只对 SQL Injection（注入缺陷的一种）进行简单介绍，如果读者感兴趣可以学习本文的参考资料或者访问 OWASP 官方网站以获得更多信息。对于用户登录来说，大多数程序都会使用如下的 SQL 语句对用户名和密码进行验证：
SELEECT * FROM user_table WHERE user_name = '' AND password = ''
通常情况下上述 SQL 语句可以对用户账号进行有效的检测，但是如果用户输入的账号信息为：用户名 'or 1 = 1--；密码 test，那么登陆程序拼接出的 SQL 语句将变为：
SELEECT * FROM user_table WHERE user_name = '' or 1 = 1--' AND password = 'test'
数据库在执行 SQL 语句时会将 "--" 后面的内容作为注释忽略掉，其结果是上述 SQL 语句永远返回真，一个非法的用户获得了网站的登录权限。为了防止此类问题我们通常会对用户输入数据的合法性进行校验，同时使用预编译语句将用户输入作为参数传递到SQL语句中。
Rational AppScan 初识
Web 安全检测主要分为两大类，分别是白盒检测和黑盒检测。白盒工具通过分析应用程序源代码以发现问题，而黑盒工具则通过分析应用程序运行的结果来报告问题。 Rational AppScan（以下简称 AppScan）属于后者，它是业界领先的 Web 应用安全检测工具，提供了扫描、报告和修复建议等功能。为使本文达到更好的效果，在继续文本前读者最好先从 developerWorks 网站下载并安装 Rational AppScan 试用版，安装完成后导入证书激活产品。证书的有效期为 30 天，授予了使用产品全部功能的权限，但是用户只可以扫描本机（localhost）或者 Rational AppScan 测试站点（http://demo.testfire.net）上部署的应用程序。需要说明的是登录 http://demo.testfire.net 站点的用户名和密码为：jsmith / Demo1234，该登录账号在后面的章节中会用到。
图 1. 开始安装
安装完成后，启动 AppScan 应用程序，其界面主要包括如下部分:
菜单栏：涵盖了 AppScan 中的所有可用功能
工具条：常用功能的快捷菜单，如开始扫描、扫描配置、扫描专家等
左上部网站导航视图：在扫描过程中 AppScan 会按照一定的层次组织显示站点结构图（默认是按照 URL 层次进行组织，用户可以在扫描配置中更改这一设置）
右上部安全问题显示视图：AppScan 将在此视图中列出检测到的所有安全缺陷
左下部安全问题汇总视图：AppScan 将在此视图中列出检测到的安全缺陷统计信息
右下部安全问题详细信息视图：此视图的内容与安全问题显示视图相关，用来显示某特定安全问题的详细信息，包括问题介绍、修复建议、测试数据等
图 2. AppScan 主界面
开始一次扫描
扫描就是 AppScan 对站点进行测试以发现安全漏洞的过程，首先它会对站点进行一次 Explore（其行为与网络爬虫类似）过程，从某一起始 URL 开始通过页面间的链接不断探索，直到站点的所有页面都被访问或者达到某设定的最大值。在 Explore 的同时，AppScan 会分析每一个发现的页面并确定是否需要对其进行测试。如果需要，AppScan 将根据设定的测试策略（后面章节有对测试策略的详细介绍）为其创建测试用例，测试用例的数量由测试策略包含的规则集决定。Explore 完成后，AppScan 将根据测试用例对站点进行测试并分析站点的响应信息以发现安全缺陷。AppScan 引入了 扫描工程 的概念对安全扫描进行管理，通过 扫描工程 用户可以配置各种参数、保存扫描结果等，下面将为读者详细介绍其创建过程。
首先点击File菜单，在子菜单中选择New，将弹出 New Scan 对话框（见图 3）。对话框中列出了 AppScan 预先提供的常用扫描模板，使用模板将可以大大简化扫描创建过程提高工作效率；当然，用户也可以根据实际情况创建自定义模板。为了方便我们选择Predefined Templates下的 demo.testfire.net，此模板是专门为测试站点 demo.testfire.net 而设立的。
图 3. New Scan 对话框
在下一个窗口中需要选择安全扫描的类型：如果是 Web 站点扫描选择Web Application Scan，如果是 Web 服务扫描选择Web Service Scan。因为我们要对 demo.testfire.net 站点进行测试，所以选择Web Applicaiton Scan并点击下一步:
图 4. 选择扫描类型
接下来是各种扫描参数的配置，包括 URL and Servers、Login Management、Test Policy 三部分，因为 AppScan 模板已经为这些参数设置了合适的值，因此不需要做任何修改直接点击下一步即可。在最后一步，AppScan 列出了扫描创建结束后的四种行为方式，每种方式的意义如下：
Start with a full automatic scan: 默认选项，AppScan 将自动开始一次完全的安全扫描，包括探索和测试两部分
Start with automatic Explore only: AppScan 将对待测试网站进行探索，但是不进行任何安全测试
Start with Manual Explore: 此选项适用于业务逻辑复杂的站点，用户需要采用手工方式引导 AppScan 对站点进行探索
I will start the scan later: AppScan 不进行任何动作，用户可以在适当时刻手工启动安全测试
此外，还有一个额外选项 Start Scan Expert when Scan Configuration Wizard is complete，询问在配置完成后是否运行 Scan Expert。如果选中，AppScan 将启动 Scan Expert 对 Web 站点进行探查并搜集相关信息进行缝隙，根据结果对扫描配置参数进行评估并提出修改建议。通过运行 Scan Expert 可以优化扫描配置、提高缺陷发现率。此处选择Start with a full automatic scan点击Finish，AppScan 将启动一次全面的安全扫描，图 6 列出了本次扫描的结果：
图 5. 结束扫描创建选项
图 6. 扫描结果
扫描配置详解
上一小节中，我们使用 AppScan 对 demo.testfire.net 站点进行安全测试发现了很多问题，深深体会到了 AppScan 在安全缺陷检测方面的强大功能。但是在创建上述扫描时我们使用了模板，扫描参数都是预先设置的，读者可能对其意义及配置方法还不甚了解，本节将对它们进行详细介绍。扫描配置参数可以在创建扫描过程中设置，也可以在创建后进行设置，其配过程和效果是完全相同的，此处只研究如何修改已创建的扫描项目。打开已创建的扫描文件，点击工具栏的Scan Configuration或者选择Tools菜单的子项Scan Configuration打开扫描配置管理面板。
登录管理
为了限制用户对站点部分功能的使用，绝大多数 Web 应用都实现了用户认证与授权即通常所说的登陆控制功能，非授权用户仅可以访问部分功能。AppScan 的安全测试是通过模拟用户对站点的访问来实现的，如果待测试站点有需要授权才能访问的内容，就必须让 AppScan 在测试过程中通过网站的认证。AppScan 提供了登录管理来实现此功能，在扫描配置面板中点击Login Management，面板右部将显示登陆管理的详细信息（如图 7 所示），有四种方式管理登陆，分别是：
Recorded：推荐方式，需要用户手工录制登录过程；当 AppScan 发现需要登陆站点时将自动重放录制过程实现登录。点击面板上的红色的 Record... 按钮，将弹出 AppScan 的内置浏览器，在此浏览器中转到登录页面，输入账户信息完成登录即可，AppScan 将自动记录登录过程。
Prompt: 当 AppScan 发现需要登陆站点时会提醒用户登录，如果网站的登陆功能使用了图片形式的验证码（每次登录验证码图片都会发生变化）或者密码变化很频繁等需要选自此种登录方式。
Automatic: 当 AppScan 发现需要登陆站点时会使用保存的账户信息填充登陆页以实现登录，此方式需要事先录入并保存账号信息。
None： 网站没有用户认证与授权功能时选择此项。
因为 AppScan 会扫描所有探测到的需要测试的页面，这就包括了登出页面，如果 AppScan 在测试中访问了登出页面就会造成用户会话终止，从而影响后续的测试。为防止此类情况的发生就必须配置面板下方的 Logout Page Detection 参数，为登出页面设置正确的匹配模式，AppScan 在根据此参数的设置跳过对登出页面的测试。该参数提供了常用的匹配模式，用户需要根据应用的实际情况进行修改。
图 7. 登录管理配置面板
如果将站点登陆设置为 Recorded 方式，在录制完成后切换到Details面板查看登录的详细信息，包括按照访问先后顺序的 URL 列表、接收到的系统参数和 Cookie 等。需要注意的一项是 In-Session Detection，此参数用来帮助 AppScan 识别当前登陆状态。举例来说，在用户登录站点后通常会在页面的某处显示如 欢迎您，尊敬的XXX先生 的欢迎信息，而用户未登录或者已经登出时则无此显示。因此我们可以将 欢迎您，尊敬的 设置为登录状态的识别模式，如果页面中存在匹配模式 AppScan 即认为当前正在登录会话中。默认情况下 AppScan 会自动比较登录前后的页面，找出其差异点作为登录识别模式，开发人员也可以手工指定登录模式。点击In-Session Pattern Selection...按钮，AppScan 将弹出登录后的页面， 用户可以在页面上选择文本信息，也可以查看页面的 HTML 源代码并选择作为模式的要素（如图 9 所示）。
图 8. 登录管理详细信息面板
图 9. 登录状态识别模式选择
探索选项
探索选项用来配置 AppScan 扫描过程中的行为，在主面板左端点击Explore Options激活探索选项配置面板（如图10所示）。该面板中需要调整的参数包括 Reduant Path Limit ：限制对相同路径的访问次数，AppScan 在扫描该路径时若访问次数达到了参数阈值即停止扫描，对于采用参数化功能跳转的应用，必须为此参数设置合理数值。 所谓参数化功能跳转即在 URI 相同情况下，通过参数控制功能使用（页面跳转）的技术。举例来说，某 Web 应用将所有的账号管理功能（包括添加账号、删除账号、查看账号详细信息等）放置在路径 /manage/account/ 下，但不为每种具体功能创建子路径而是将功能与特定参数的值建立映射关系，如将添加账户功能映射到 action=ADD_ACCOUNT，将删除账户功能映射到 action=DEL_ACCOUNT。 要访问添加账户页面，需要在发送请求到 /manage/account/ 的同时发送参数 action=ADD_ACCOUNT。此参数设置的正确与否将在很大程度上影响测试效果。
Depth Limit： 参数用来控制扫描的最大深度，AppScan 会从网站的入口页面开始根据页面上发现的 URL 爬行，当到达页面与起始页面的深度超出参数阈值时，它将停止对当前页面的扫描返回上一级。Link Limit：用来控制 URL 的总访问数量，默认设置是没有任何限制，如果设置了数值，那么当被访问的 URL 数量到达阈值时 AppScan 将结束扫描。 Appscan 有两种可选择的探索方式，分别是广度优先（默认设置）和深度优先，可根据应用实际情况选择合理的设置（如对所提供功能强调前后关联关系的的应用比较适合深度优先）。
图 10. 探索选项
Parameter与Cookie
在主面板左端点击Parameters and Cookies激活配置面板，此视图中列出了 AppScan 测试过程中维护的所有参数，扫描时 AppScan 在每个发送的测试请求中包含列表中的参数及其对应值。AppScan 会自动向此列表中添加 Explore 期间发现的参数和 Cookie，也可以通过点击面板上的+按钮手动添加参数（如图11所示）。添加的参数可分为有三种类型：Parameter、Cookie 和 Custome，因为 Custome 类型的参数配置比较复杂且应用较少，故本文只简单介绍 Parameter 的创建。
假如我们需要在发送的每次测试请求中包括 categoryID 这个参数，那么为添加此参数的设置为：
Parameter name: categoryID；勾中Track this parameter during scan
使 AppScan 在扫描过程中对参数值的变化进行追踪，有三种方式可供选择：Login Value 指 AppScan 将保存登录过程中接收到的值，此值在后续测试过程中不会发生改变；Dynamic 指 AppScan 在每次的测试响应中寻找此参数的值，如果发现则使用新找到的值更新当前值；Fixed Value 表明此参数的值不会发生任何变化，AppScan 将始终使用用户输入的值。
AppScan 为参数提供了Redundancy Tuning选项，此参数的正确设置可以减少测试冗余、提高测试效率。假设我们需要测试如下四个 URL 并且 timezone 参数只是为了在页面上显示时间之用，对应用的功能没有任何影响:
| # | Detail |
| 1 | viewProducts.do?timezone=
1 &filter=IBM |
| 2 | viewProducts.do?timezone=
2 &filer=IBM |
| 3 | viewProduction.do?
timezone=1 &filter=IBM |
| 4 | viewProduction.do?filer=IBM |
可见，对于 URL 1 和 URL 2，其不同之处仅仅在于 timezone 的值，对于 URL 3 和 URL 4，其不同之处仅仅在于是否包含 timezone 参数，Redundancy Tuning 参数设置如下：
When comparing Explore requests, ignore this parameter's value：对于两个或者两个以上的 URL，如果其不同之处仅仅在于某参数的值（如 URL 1 和 URL 2）而此参数值对应用的功能没有任何影响，那么选中此项使 AppScan 在探索过程中只探索其中的一个 URL 而将其它的丢弃
When comparing Explore requests, ignore this parameter altogether：对于两个或者两个以上的 URL，如果其不同之处仅仅在于是否包含某参数（如 URL 3 和 URL 4）而此参数对应用的功能没有任何影响，那么选中此项使 Appscan 在探索过程中只探索其中的一个 URL 而将其它的丢弃
Don't retest adjacent parameters when this parameter's value changes：对于两个或者两个以上的URL，如果其不同之处仅仅在于某参数的值（如 URL 1 和 URL 2）而此参数值对应用的功能没有任何影响，那么选中此项使 AppScan 在测试过程中只测试其中的一个 URL 而将其它的丢弃
Don't retest adjacent parameters when this parameter is added/removed：对于两个或者两个以上的URL，如果其不同之处仅仅在于是否包含某参数（如 URL 3 和 URL 4）而此参数对应用的功能没有任何影响，那么选中此项使 AppScan 在测试过程中只测试其中的一个 URL 而将其它的丢弃
图 11. 添加参数
多步骤操作
对于复杂应用，要完成某项任务往往需要很多步骤，步骤之间有很强的顺序依赖关系。以某系统的转账功能为例，用户受限需要输入对方的账号和姓名点击下一步；如果系统验证账号和姓名正确则要求输入转账金额，否则返回上一步，在输入金额后点击下一步进入确认界面；系统将列出前两步操作中的所有信息供用户确认，如确认无误点击确认完成转账。可见要完成转账操作需要三步，这三步之间是前后依赖的，只有完成了上一步才可以继续下一步，如果直接访问转账金额页面或者最终确认页面应用会显示错误信息。我们知道 AppScan 会测试所有发现的URL，对这些URL的测试时随机的，它并不能保证对存在依赖关系的URL的测试是按照顺序的，这就可能造成 AppScan 首先访问后续步骤页面，从而影响安全测试结果。 为了解决问题，AppScan 引入了多步骤序列的概念。点击主配置面板左边的Multi-Step Opetions打开多步骤操作视图，此视图中列出了所有已经创建的操作序列，可以将存在的序列导出成单独文件，也可以导入曾经被导出的序列文件；点击红色的按钮会弹出 AppScan 内置的浏览器，在此浏览器中用户只需像平时使用应用一样完成某项功能即可，关闭浏览器即完成序列脚本的录制。在测试过程中，AppScan 会将当前待测试的URL与录制的序列脚本中的URL进行比较，如果发现待测URL是某个序列中的一步，AppScan 会重放所有前置序列脚本以使对当前页面的访问合法
图 12. 多步骤操作
策略定制
AppScan 会通过预先设定的安全规则创建测试用例，一条安全规则描述了某安全缺陷的信息，包括缺陷描述、修复建议、确认模式等。AppScan 集成了大规模的测试规则，默认情况下针对一个页面可能会生成成百上千个测试用例，但是这些用例中往往有很大一部分对于应用本身来说是没有任何意义的。为了减少测试冗余、增加测试的有效性就需要甄选符合应用实际情况的的测试规则，比如针对J2EE站点的安全测试就不需要与.Net相关的测试规则，又如对安全性要求不高的站点（内部应用）只需要对高危险的安全缺陷进行探测而没必要测试所有。测试策略是对测试规则的管理，用户可以根据 Web 应用的实际项目情况选择合理的测试规则集， 对选定的规则集可以通过Export的方式将其导出为策略文件，其它用户可以导入策略文件以保持组织内部策略规则的一致性。点击主配置面板左端的Test Policy打开测试策略视图（如图 13 所示），视图中列出了 AppScan 的所有测试规则，可以通过上面的分组下拉框对其按照不同方式进行分组以方便查看。
图 13. 测试策略
上面对 AppScan 常用配置做了简要描述，扫描配置还包括 URL and Servers，Environment Definition，Error Pages，Content-Based Results等项目，限于篇幅不一一介绍，读者可以参考developerWorks上的相关资源以获得更多信息。
结束语
IBM Rational AppScan 是一款强大的安全缺陷检测工，提供了扫描、报告和修复建议等功能，对提高 Web 应用安全有巨大作用。
