Rational AppScanWeb应用软件安全性测试工具的初步认识.doc

AppScan 学习参考内容/ceshi/ceshijishu/rjcsgj/rational/appscan/ Rational AppScan 是专门面向 Web 应用安全检测的自动化工具，是对 Web 应用和 Web Services 进行自动化安全扫描的黑盒工具。它不但可以简化企业发现和修复 Web 应用安全隐患的过程（这些工作以往都是由人工进行，成本相对较高，效率低下），还可以根据发现的安全隐患，提出针对性的修复建议，并能形成多种符合法规、行业标准的报告，方便相关人员全面了解企业应用的安全状况。利用 Rational AppScan，应用程序开发团队在项目交付前，可以对所开发的应用程序与服务进行安全缺陷的扫描，自动化检测 Web 应用的安全漏洞，从网站开发的起始阶段就扫除 Web 应用安全漏洞。 Rational AppScan 工作原理Rational AppScan(简称 AppScan)其实是一个产品家族，包括众多的应用安全扫描产品，从开发阶段的源代码扫描的 AppScan source edition【从代码开始使用复合技术保证 Web 应用安全】，到针对 Web 应用进行快速扫描的 AppScan standard edition【桌面解决方案扫描和测试漏洞和安全缺陷】，以及进行安全管理和汇总整合的 AppScan enterprise Edition【将先进的应用程序安全测试与整个应用程序生命周期中的治理、协作和安全性智能相结合。它使企业能够降低应用程序风险，控制应用程序项目成本】 等。我们经常说的 AppScan 就是指的桌面版本的 AppScan，即 AppScan standard edition。其安装在 Windows 操作系统上，可以对网站等 Web 应用进行自动化的应用安全扫描和测试。来张 AppScan 的截图，用图表说话，更明确。图 1. AppScan 标准版界面请注意右上角，单击“扫描”下面的小三角，可以出现如下的三个选型“继续完全扫描”、“继续仅探索”、“继续仅测试”，有木有?什么意思?理解了这个地方，就理解了 AppScan 的工作原理，我们慢慢展开：还没有正式开始安全测试之前，所以先不管“继续”，直接来讨论“完全扫描”，“仅探索”，“仅测试”三个名词：AppScan 三个核心要素AppScan 是对网站等 Web 应用进行安全攻击来检查网站是否存在安全漏洞;既然是攻击，需要有明确的攻击对象吧，比如现在的对象就是卡扎菲上校还有他的军队。对网站来说，一个网站存在的页面，可能成千上万。每个页面也都可能存在多个字段(参数)，比如一个登陆界面，至少要输入用户名和密码吧，这就是一个页面存在两个字段，你提交了用户名密码等登陆信息，网站总要有地方接受并且检查是否正确吧，这就可能存在一个新的检查页面。这里的每个页面的每个参数都可能存在安全漏洞，所有都是被攻击对象，都需要来检查。这就存在一个问题，我们来负责检查一个网站的安全性，这个网站有多少个页面，有多少个参数，页面之间如何跳转，我们可能并不明确，如何知道这些信息?看起来很复杂，盘根错节;那就更需要找到那个线索，提纲挈领;想一想，访问一个网站的时候，我们需要知道的最重要的信息是哪个?网站主页地址吧?从网站地址开始，很多其他频道，其他页面都可以链接过去，对不对，那么可不可以有种技术，告诉了它网站的入口地址，然后它“顺藤摸瓜”，找出其他的网页和页面参数?OK，这就是“爬虫”技术，具体说，是“网站爬虫”，其利用了网页的请求都是用 http 协议发送的，发送和返回的内容都是统一的语言 HTML，那么对 HTML 语言进行分析，找到里面的参数和链接，纪录并继续发送之，最终，找到了这个网站的众多的页面和目录。这个能力 AppScan 就提供了，这里的术语叫“探索”，explorer，就是去发现，去分析，了解未知的，并记录之。在使用 AppScan 的时候，要配置的第一个就是要检查的网站的地址，配置了以后，AppScan 就会利用“探索”技术去发现这个网站存在多少个目录，多少个页面，页面中有哪些参数等，简单说，了解了你的网站的结构。“探索”了解了，测试的目标和范围就大致确定了，然后呢，利用“军火库”，发送导弹，进行安全攻击，这个过程就是“测试”;针对发现的每个页面的每个参数，进行安全检查，检查的弹药就来自 AppScan 的扫描规则库，其类似杀毒软件的病毒库，具体可以检查的安全攻击类型都在里面做好了，我们去使用即可。那么什么是“完全测试呢”，完全测试就是把上面的两个步骤整合起来，“探索”+“测试”;在安全测试过程中，可以先只进行探索，不进行测试，目的是了解被测的网站结构，评估范围;然后选择“继续仅测试”，只对前面探索过的页面进行测试，不对新发现的页面进行测试。“完全测试”就是把两个步骤结合在一起，一边探索，一边测试。AppScan 工作原理小结如下：通过搜索(爬行)发现整个 Web 应用结构根据分析，发送修改的 HTTP Request 进行攻击尝试(扫描规则库)通过对于 Respone 的分析验证是否存在安全漏洞图 2. AppScan 扫描原理：扫描规则库 + 爬行 + 测试步骤 1：探索(又叫爬行，爬网)图 3. 探索(爬网，爬行)步骤 2：测试(针对找到的页面，生成测试，进行安全攻击)图 4. 针对探索发现的页面和参数，进行安全测试所以，简言之，AppScan 的核心是提供一个扫描规则库，然后利用自动化的“探索”技术得到众多的页面和页面参数，进而对这些页面和页面参数进行安全性测试。“扫描规则库”，“探索”，“测试”就构成了 AppScan 的核心三要素。而在安全扫描过程中，如何进行优化，就要结合这三个要素，看哪些部分需要优化，应该如何优化。AppScan 结果文件同时，对于 AppScan 标准版来说，扫描的配置和结果信息都保存为后缀名为 Scan 文件，Scan 文件里面主要包括的内容如下：扫描配置信息：扫描配置信息，如扫描的目标网站地址，录制的登陆过程脚本等，选择的扫描设置等都保存在 Scan 文件中。所有访问到页面信息：针对每个发现的页面，即使没有进行测试，在探索过程也会访问该页面并纪录 http request/response 信息;所以如果探索的页面访问的时候返回的页面内容比较多，页面比较大，那么即使只做了探索根本没有扫描，整个 Scan 文件也会很大。测试阶段，记录测试成功的测试变体和页面访问信息：针对每个页面都会发送多次测试(测试变体)，每次测试都会有 Request/response 信息，这些信息如果测试通过，即发现了一个安全问题，则会把该测试变体对应得 request/response 都会纪录下来，保存在 .scan 文件中;由于 AppScan 的扫描测试用例库全面，对于每种安全威胁漏洞，都会发送多个安全测试变体(Variant)进行测试，比如对于 XSS 问题，AppScan 发送了 100 个变体，其中 30 个执行失败，70 个变体执行成功，则会纪录 70 次执行成功的具体变体信息，以及每个变体对应的 Request/Response 信息。这就是一个很大的数据量。这些信息保存以后，就可以在不连接在网站的情况下进行结果分析，快速显示当时测试的页面快照等。我们以/bank/customize.aspx 为例，如下就有 74 个变体都发现了 Customize 页面的 Lang 参数存在跨站点脚本执行(XSS)类型的安全漏洞：图 5. 测试变体显示所以针对 AppScan 标准版来说，由于需要保存的信息比较多，结果文件是会比较大的，最根本的方法还是有针对性地进行扫描和测试，使用排除页面等排除冗余页面，把一个大的系统分解为多个小的扫描任务等。好的，了解了 AppScan 的原理，我们就结合原来讨论下为什么扫描大型网站时候可能遇到问题了。大型网站技术特点分析AppScan 扫描的对象是网站等 Web 应用，而网站规模的大小和使用的技术，都需要针对性的进行扫描设置，我们遇到的很多问题，都是在扫描规模比较大的网站时候遇到的，如一个网站页面数目超过 2000 个，需要执行的扫描用例是 50，000 个，在扫描这样的网站时候，默认情况下 AppScan 的扫描 scan 文件可能超过 100M 了，扫描效率就可能比较慢，需要长时间的扫描运行时间。下面，我们就来分析大型网站中存在的一些可能影响 AppScan 扫描的技术特点。网站页面多，页面参数多，则 AppScan 需要发送的测试用例多什么叫大型网站，顾名思义，网站规模大，提供内容多;具体说是页面很多，内容很全。比如 ，比如/，网站中都有多个频道，包括上万个页面。而且除了页面多，可能还有一个特点 - 页面参数多，即要填写的地方多，和用户的交互多;比如一个网站如果都是静态页面(.html、.jpg 等)，没有让用户输入的地方，那么可以利用，可以作为攻击点的地方也就不多。如果页面到处都是有输入有查询，要求用户来参与的，你输入的越多，可能泄露的信息也越多，可能被别人利用的攻击点也就越多，所以和页面参数也是有关系的。AppScan 产生测试用例的时候，也是根据每个参数来产生的，简单说，如果一个参数，对应了 200 个安全攻击测试用例，那么一个登陆界面至少就对应 400 个了，为什么?登陆界面至少有用户名(username)和密码(password)两个字段吧?每个字段 200 个攻击用例。这个简单吧，还可以更复杂：如果遇到下面的两个地址，那要扫描多少次呢?http:/www.T/focus/satisfy/file.jsp?id=1http:/www.T/focus/satisfy/file.jsp?id=2上面的两个地址有类似的，“?”号以前的 URL 地址完全一样，“?”号后面带的参数不同，这种可以认为是重复页面，那么对于重复页面，是否要重复测试呢?这取决于“冗余路径设置”，默认的是最多测试 5 次;即，这种类型 URL 出现的前 5 次，那么就是要测试 1000 个攻击用例了。如果再继续修改下：遇到下面的 URL 呢http:/www.T/focus/satisfy/file.jsp?id=&Item=openhttp:/www.T/focus/satisfy/file.jsp?id=2&Item=close每个 URL 里面都有 2 个参数，测试的次数就更多了。想象下，如果这个网页里面的参数如果是 10 个，或者更多的呢?比如很多网站提交注册信息的时候，要填写的栏位就很多，要进行的安全测试用例也就随之不断增加这是网站规模的影响，还有一个问题，就出在“每个参数，发送 200 个安全测试用例”这个假设上。这个假设的前提来源于哪里?来源于我们选择的扫描规则库。即你关心那些安全威胁，这个需要在测试策略里面选择。同样来参照杀毒软件，你会用杀毒软件来查找一些专用的病毒吗，比如 CIH、木马;应用安全扫描也是一样的道理，如果有明确的安全指标或者安全规则范围，那么就选择之。这些可能来源于企业的规范，来源于政府的法律法规。就要根据你的理解，在这里选择。图 6. 选择测试策略在实际工作中，我们也很难在最开始的阶段，就把扫描规范制定下来，按照项目经理们的口头禅“渐进明细”，“滚动式规划”，在实践中，更多时候也是摸着石头过河，选择了一个扫描策略，然后根据结果分析，看是否需要调整，不断优化。比如选择默认的“缺省值”扫描策略，对网站进行扫描，发现其“敏感信息”里面会去检查页面上是否含有 Email 地址，是否含有信用卡号码等，如果我们觉得这些信息，显示在页面上是正常的业务需要(比如这样的链接：有问题请联系 )，我们就可以取消掉这些规则，所以扫描规则也很大程度上影响着我们的扫描效率。网站采用多种混合的技术，需要不同的扫描设置一些大型网站，往往是一个统一的入口，在里面提供不同的内容，而这些内容可能来源于不同的技术。如我们熟悉的门户网站，里面就有“财经”、“体育”、“娱乐”等多个频道;每个频道的内容，可能是采用不同的技术，对应不同的服务器。如一个网站的“论坛”频道，就有很多类似的页面：http:/www.T/bbs/showthread.php?id=1Http:/www.T/bbs/showthread.php?id=2Http:/www.T/bbs/showthread.php?id=3这里的 showthread.php 页面存在多次，每次都是参数值不同，访问后发现这些页面除了文本内容外，其他的页面结构等都相同，则这些页面只需要选择几个典型的扫描即可，没有必要全部扫描。而同时，在另外的一些频道，存在另外类型的页面：http:/www.T/default.aspx?content=inside_community.htmhttp:/www.T/default.aspx?content=inside_press.htmhttp:/www.T/default.aspx?content=inside_executives.htm这些动态页面，也是网址相同，参数相同，但是具有不同的参数值，访问时候发现每种类型的参数值都指向了完全不同的页面，则需要每种参数值都要测试到。这种情况经常存在跳转页面中。而这两个频道中，第一种情况，可以选择典型的页面扫描之，而第二种情况则需要进行完全的扫描，每种参数值都需要考虑到。这就需要不同的扫描设置。同时，可能大家也注意到了，第一种情况下的是 php 页面，而第二种情况下的则是 aspx 页面，对应不同的开发技术，这也可能需要不同的扫描设置。所以，总结下，AppScan 的扫描受到如下因素的影响：网站规模(页面个数，页面参数)扫描策略的选择扫描设置而对于大型的网站，我们经常需要从几个方面来优化配置选择合适的，最小化的扫描规则分解扫描任务，把一个大的扫描任务分解为多个小的扫描任务根据页面特点，设置可以过滤的类似页面(冗余页面) 工具简单了解基于 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*FROMuser_tableWHEREuser_name=ANDpassword=通常情况下上述 SQL 语句可以对用户账号进行有效的检测，但是如果用户输入的账号信息为：用户名 or 1 = 1-；密码 test，那么登陆程序拼接出的 SQL 语句将变为：SELEECT*FROMuser_tableWHEREuser_name=or1=1-ANDpassword=test数据库在执行 SQL 语句时会将 - 后面的内容作为注释忽略掉，其结果是上述 SQL 语句永远返回真，一个非法的用户获得了网站的登录权限。为了防止此类问题我们通常会对用户输入数据的合法性进行校验，同时使用预编译语句将用户输入作为参数传递到SQL语句中。Rational AppScan 初识Web 安全检测主要分为两大类，分别是白盒检测和黑盒检测。白盒工具通过分析应用程序源代码以发现问题，而黑盒工具则通过分析应用程序运行的结果来报告问题。 Rational AppScan（以下简称 AppScan）属于后者，它是业界领先的 Web 应用安全检测工具，提供了扫描、报告和修复建议等功能。为使本文达到更好的效果，在继续文本前读者最好先从 developerWorks 网站下载并安装 Rational AppScan 试用版，安装完成后导入证书激活产品。证书的有效期为 30 天，授予了使用产品全部功能的权限，但是用户只可以扫描本机（localhost）或者 Rational AppScan 测试站点（）上部署的应用程序。需要说明的是登录 站点的用户名和密码为：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【预定义的模板】下的 ，此模板是专门为测试站点 而设立的。图 3. New Scan【新建扫描】 对话框 在下一个窗口中需要选择安全扫描的类型：如果是 Web 站点扫描选择Web Application Scan【Web 应用程序扫描】，如果是 Web 服务扫描选择Web Service Scan【Web Service 扫描】。因为我们要对 站点进行测试，所以选择Web Applicaiton Scan【Web 应用程序扫描】，并点击下一步:图 4. 选择扫描类型 查看原图（大图）接下来是各种扫描参数的配置，包括 URL and Servers【URL和服务器】、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 对 站点进行安全测试发现了很多问题，深深体会到了 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”的欢迎信息，而用户未登录或者已经登出时则无此显示。因此我们可以将“欢迎您，尊敬的XXX”设置为登录状态的识别模式，如果页面中存在匹配模式 AppScan 即认为当前正在登录会话中。默认情况下 AppScan 会自动比较登录前后的页面，找出其差异点作为登录识别模式，开发人员也可以手工指定登录模式。点击Selection In-Session Pattern .【选择会话中模式】按钮，AppScan 将弹出登录后的页面， 用户可以在页面上选择文本信息，也可以查看页面的 HTML 源代码并选择作为模式的要素（如图 9 所示）。图 8. 登录管理详细信息面板 查看原图（大图）图 9. 登录状态识别模式选择 查看原图（大图）探索选项探索选项用来配置 AppScan 扫描过程中的行为，在主面板左端点击Explore Options【探索选项】激活探索选项配置面板（如图10所示）。该面板中需要调整的参数包括 Redundant 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. 探索选项 查看原图（大图）Parameters与Cookie【参数和cookie】在主面板左端点击Parameters and Cookies【参数和cookie】激活配置面板，此视图中列出了 AppScan 测试过程中维护的所有参数，扫描时 AppScan 在每个发送的测试请求中包含列表中的参数及其对应值。AppScan 会自动向此列表中添加 Explore 期间发现的参数和 Cookie，也可以通过点击面板上的“+”按钮手动添加参数（如图11所示）。添加的参数可分为有三种类型：Parameter、Cookie 和 Custome【参数、cookie、定制参数】，因为 Custome 类型的参数配置比较复杂且应用较少，故本文只简单介绍 Parameter 的创建。假如我们需要在发送的每次测试请求中包括 categoryID 这个参数，那么为添加此参数的设置为：Parameter name: categoryID；勾中 Track this parameter during scan【在扫描过程中跟踪该参数】使 AppScan 在扫描过程中对参数值的变化进行追踪，有三种方式可供选择：Login Value【登录值】 指 AppScan 将保存登录过程中接收到的值，此值在后续测试过程中不会发生改变；Dynamic Value【动态值】 指 AppScan 在每次的测试响应中寻找此参数的值，如果发现则使用新找到的值更新当前值；Fixed Value【固定值】表明此参数的值不会发生任何变化，AppScan 将始终使用用户输入的值。AppScan 为参数提供了Redundancy Tuning【冗余调整】选项，此参数的正确设置可以减少测试冗余、提高测试效率。假设我们需要测试如下四个 URL 并且 timezone 参数只是为了在页面上显示时间之用，对应用的功能没有任何影响:#Detail1viewProducts.do?timezone= 1&filter=IBM2viewProducts.do?timezone= 2&filer=IBM3viewProduction.do? timezone=1&filter=IBM4viewProduction.do?filer=IBM可见，对于 URL 1 和 URL 2，其不同之处仅仅在于 timezone 的值，对于 URL 3 和 URL 4，其不同之处仅仅在于是否包含 timezone 参数，Redundancy Tuning【冗余调整】参数设置如下：When comparing Explore requests, ignore this parameters value【当比较探索请求时，忽略该参数的值】：对于两个或者两个以上的 URL，如果其不同之处仅仅在于某参数的值（如 URL 1 和 URL 2）而此参数值对应用的功能没有任何影响，那么选中此项使 AppScan 在探索过程中只探索其中的一个 URL 而将其它的丢弃When comparing Explore requests, ignore this parameter altogether【当比较探索请求时，完全忽略该参数】：对于两个或者两个以上的 URL，如果其不同之处仅仅在于是否包含某参数（如 URL 3 和 URL 4）而此参数对应用的功能没有任何影响，那么选中此项使 Appscan 在探索过程中只探索其中的一个 URL 而将其它的丢弃Dont retest adjacent parameters when this parameters value changes【当该参数的值更改时，不要重新测试相邻参数】：对于两个或者两个以上的URL，如果其不同之处仅仅在于某参数的值（如 URL 1 和 URL 2）而此参数值对应用的功能没有任何影响，那么选中此项使 AppScan 在测试过程中只测试其中的一个 URL 而将其它的丢弃Dont retest adjacent parameters when this parameter is added/removed