使用 AppScan 进行扫描

针对大型网站的扫描，咱们按照戴明环 PDCA 的方法论来进行规划和讨论，建议 AppScan 使用步骤：计划（Plan）、执行（Do）、检查（check）、分析（Analysis and Action）。php

在计划阶段：明确目的，进行策略性的选择和任务分解。
1. 明确目的：选择合适的扫描策略
2. 了解对象：首先进行探索，了解网站结构和规模
3. 肯定策略：进行对应的配置
4. 按照目录进行扫描任务的分解
5. 按照扫描策略进行扫描任务的分解
执行阶段：一边扫描一遍观察
1. 进行扫描
2. 先爬后扫（继续仅测试）
检查阶段（Check）
1. 检查和调整配置
结果分析（Analysis）
1. 对比结果
2. 汇总结果（整合和过滤）

下面咱们针对每一个阶段，进行具体的阐述。html

准备阶段

AppScan 安装环境要求和检查

为了保证更好的扫描效果，安装 AppScan 的硬件建议配置以下：python

表 1. Rational AppScan 安装配置要求

 
          1 
        
          2 
        
          3 
        
          4 
        
          处理器 　　　　 　Pentium P4， 
          2.4  
          GHz 
         
          内存            
          2  
          GB RAM 
         
          磁盘空间    　　　　   
          30  
          GB 
         
          网络            
          1  
          NIC  
          100  
          Mbps（具备已配置的 TCP 
          / 
          IP 的网络通讯）

　　其中，处理器和内存建议越大越好，而磁盘空间，建议系统盘（通常是 C 盘）磁盘空间至少保留 10G，若是系统盘磁盘空间比较少，能够考虑把用户文件等保存在其余盘；如默认的用户文件是：C:\Documents and Settings\Administrator\My Documents\AppScan；能够修改成其余路径。该路径能够在菜单栏中依次选择工具 - 选项 - 通常 - 文件位置部分修改。正则表达式

磁盘要求：修改临时文件路径

有时候你们会发现，已经把上面的地址都修改到了其余盘，可是在扫描过程当中，仍是会发现 C 盘的空间快速被消耗，分析缘由，是由于不少临时文件都保存在 C 盘，AppScan 中有一个隐藏的参数 APPSCAN_TEMP 来设置临时文件位置。在扫描过程当中，若是系统盘空间比较下，能够经过修改系统变量来修改到其余硬盘空间。数据库

临时文件位置说明：描述正常操做期间 AppScan 将其临时文件保存到的位置。缺省状况下，AppScan 将其临时文件存储在如下位置：浏览器

C:\Documents and Settings\All Users\Application Data\IBM\Rational AppScan\temp安全

若是须要修改此缺省位置，请按照要求编辑环境变量 APPSCAN_TEMP 的路径。（访问环境变量的方法是，右键单击个人电脑，而后依次选择属性 > 高级 > 环境变量。）服务器

注意：在新位置的路径中毫不能有任何 Unicode 字符。cookie

修改 AppScan 中的临时文件：网络

桌面上鼠标右键选择“个人电脑”，选择“属性”
选择“高级”，“环境变量”
增长一个新的“用户环境变量”，名字是“APPSCAN_TEMP”，设定路径，指向您但愿保存临时文件的目录。

计划阶段

在计划阶段，首先明确几个问题：

关心哪些类型的安全问题，根据这些安全问题来设置扫描规则。
要扫描的网站地址，网站的业务特色。

扫描策略的选择

试想，咱们如今要扫描的是某个移动公司的网站系统，该网站系统提供多个内容频道，还能够链接到多个其余移动公司网站和业务网站，咱们本次安全测试重点关心的是门户网站自己和其上面的网上营业厅业务。这就是一个比较明确的测试目标对象。

而后，肯定扫描策略，咱们主要关心该网站是否存在跨站点脚本执行和 SQL 注入的问题，则在扫描规则中，咱们就能够选择这两种类型的规则，其余规则都排除。

具体的扫描规则定制，能够在扫描配置 - 测试 - 测试策略中选择：

在测试策略中，有多种不一样的分组模式，最常用的是“严重性”，“类型”，“侵入式”、“WASC 威胁分类”等标准，根据不一样分组选择的扫描策略，最后组成一个共同的策略集合。

根据咱们此次扫描的目标，关心的是跨站点脚本执行和 SQL 注入的问题，并且不考虑“基础结构”级别的安全问题。则就能够首先选择一个默认的扫描策略，而后所有置空，再选择

跨站点脚本执行和 SQL 注入，最后再去除这两种扫描策略中和基础结果相关的安全问题。

方法以下：

选择缺省的扫描策略，或者把当前的扫描策略，切换到按照“类型”分类，取消掉“基础结构”和“应用程序”两种类型。说明：则把扫描策略置空，没有选择任何的扫描策略，指全部分布类型选择“类型”分类，是由于类型分类里面含有的类型，只有两种类型，能够快速所有都取消掉。

分组类型，切换到“WASC 威胁分类”，选择“SQL 注入”和“跨站点脚本编制”。
分组类型，切换到“类型”，发现这时候“基础结构”和“应用程序”两种类型的扫描策略都是选择上的模式，并且是虚线，说明这两种类型下均有部分扫描策略被选择了。
咱们不关心“基础结构”级别的安全问题，因此在这里取消“基础结构”。

分组类型，切换到“侵入式”类型，下面有“非侵入式”和“侵入式”两种分类。取消“基础结构”级别的测试。

侵入式的测试用例，每每由于有比较强的反作用，可能对系统形成伤害，因此通常扫描生产系统的时候，不多选择。咱们能够查看一个 SQL 注入类型的侵入式安全问题，在“输入以查找”输入框中输入“SQL”，而后回车查询。能够看到测试变体的描述“将参数值设置为 Declare/Case SQL 注入攻击（尝试关闭 DB 服务器）”，则扫描过程当中，会使用该测试用例去执行尝试关闭数据库的命令，若是该测试用例执行经过，则就关闭了数据库，则整个系统就瘫痪！因此，要很慎重的选择“侵入式的测试用例”。

其余的在“类型”中，“应用程序”类型表示该问题的存在是由于应用程序不严谨，代码存在安全问题而形成的，修改方法就是修改原代码；而“基础结构”类型，则表示该问题是配置问题，建议修改系统配置或者安装最新的补丁（常常是中间件或数据库补丁）。

了解被测试网站

在对网站进行测试以前，咱们常常须要先大概了解下这个网站，好比该网站使用了哪些技术，提供什么类型的业务（功能），网站规模等。这些都和咱们的扫描设置相关。以下图，就是咱们常用的一个调查表，了解被测试系统的基本特色。

表 2. 记录被测网站特色

应用系统名称	访问地址	应用系统架构（JEE/.Net/PHP…）	URL 数量	登录方式	备注

其中，用户常常迷惑的是 URL 数量，有些时候，用户很难评估出一个系统的大概页面数量，而按照 AppScan 的工做原理，扫描是针对页面的每一个参数的，若是页面越多，参数越多，则扫描要运行的时间也就越长，扫描保存成的接过文件也是越大，更须要进行分解。若是一个扫描任务，自己的已访问 URL 数超过 5000，评估的要运行的安全测试用例数超过 50，000，则建议进行扫描配置的分析，并根据分析结果，决定是否须要进一步的任务分解和分工。

那么，若是能够了解到网站具体有哪些页面呢？这里咱们就能够利用 AppScan 的探索（页面爬行）能力。

在扫描配置里面设置了主 URL 之后，工做菜单中中依次选择扫描 - 仅探索。对网站进行探索。通常会让探索工具运行 10 到 30 分钟，看该网站具体存在哪些页面，哪些参数等。这个就能够切换到“应用程序数据”视图来查看。

咱们通常关心这几个视图：

已访问的 URL()：AppScan 已经探索到而且进行了分析的页面
已过滤掉的 URL()：AppScan 已经发现，同时根据扫描配置，认为不须要进行安全扫描的页面。
中断连接 URL()：AppScan 发现了，可是没法访问到或者访问出错的页面，如 404 页面不存在，或者 500 服务器错误等。

伪静态页面

能够选择左边“个人应用程序数据”中的 URL 树下的每个节点，察看该节点已访问的 URL，已过滤掉的 URL 等。

如在已访问的 URL() 中，咱们发现大量相似以下结构的 HTML 页面：

 
     
      
       
          1 
        

          2 
        

          3 
        
 
        
          http: 
          / 
          / 
          www.Test.com 
          / 
          / 
          focus 
          / 
          satisfy 
          / 
          file5.html 
         
 
          http: 
          / 
          / 
          www.Test.com 
          / 
          / 
          focus 
          / 
          satisfy 
          / 
          file6.html 
         
 
          http: 
          / 
          / 
          www.Test.com 
          / 
          m 
          - 
          zone 
          / 
          news 
          / 
          dgdd 
          / 
          quanbu 
          / 
          bylb 
          / 
          file5.html 
         
 
      
 
     
   

　　其共同特征，都是以 html 为后缀名，最后的文件名格式都是 file+ 数字格式；这种类型的页面常常存在新闻，论坛等。若是访问这些页面，发现页面结构相同，差别的都是里面的文本内容，如提供不一样的新闻内容等，这些页面就是所谓的“伪静态页面”，实际上是网站发布系统动态产生的，因为结果类似，在安全扫描中，没有必要针对这些页面每次都进行扫描。如针对每一个目录下面存在的 file+ 数字格式的页面，咱们就能够设置正则表达式来过滤，好比，在扫描配置 - 排除路径和文件中

排除全部该类型的页面；.*file\d+.html

增长“例外”，对该类型的页面只扫描 file1.html 和 file20.html

常常存在的其余相似页面，还有 news1.html、content200.html 等类型，采用方法相似。

业务类型的“冗余路径”

和“伪静态页面”对应的有另一种动态页面，这些页面按照默认的扫描规则，会被自动过滤，可是根据真实的业务场景，这些页面确实不能被过滤的，如访问 demo.testfire.net 时候在“已过滤 URL”内会显示有以下的 URL 地址，过滤缘由都是“路径限制”：

 
          1 
        
          2 
        
          3 
        
          http: 
          / 
          / 
          www.Test.com 
          / 
          default.aspx?content 
          = 
          inside_community.htm 
         
          http: 
          / 
          / 
          www.Test.com 
          / 
          default.aspx?content 
          = 
          inside_press.htm 
         
          http: 
          / 
          / 
          www.Test.com 
          / 
          default.aspx?content 
          = 
          inside_executives.htm

选择 URL 地址，鼠标右键“在浏览器中显示”，会发现这里显示的页面内容彻底不同，和上面的“伪静态页面”正好相反，这些参数相同，参数值不一样的动态页面，是真正的业务页面，是不能过滤掉；若是过滤，则会不少后续的业务页面没法发现。那这些页面为何会被过滤了呢？按照什么样的规则被过滤掉的？

在 AppScan 中，默认状况下是有一个“冗余路径限制”（在“扫描配置 - 探索选型 - 冗余路径限制”），默认对于冗余的页面，最多扫描 5 次，关键的问题是，什么页面被 Appscan 认为是冗余页面呢 ?

简单说：

 
          1 
        
          http: 
          / 
          / 
          www.Test.com 
          / 
          default.aspx?content 
          = 
          inside_community.htmhttp: 
          / 
          / 
          www.Test.com 
          / 
          default.aspx?content 
          = 
          inside_press.htm

Appscan 是根据“?”号来分隔的，若是 ? 号前面的内容都相同，则就被认为是冗余页面，因此上面的页面就是冗余页面了。

遇到这样状况的页面，最多被访问 5 次。而这 5 次，具体是使用了哪些参数，是随机的，具体访问到的页面也会在“应用程序数据”视图的“已访问的 URL”中查看：

 
     
      
       
          1 
        
 
        
          http: 
          / 
          / 
          www.Test.com 
          / 
          default.aspx?content 
          = 
          business.htmhttp: 
          / 
          / 
          www.Test.com 
          / 
          default.aspx?content 
          = 
          business_lending.htmhttp: 
          / 
          / 
          www.Test.com 
          / 
          default.aspx?content 
          = 
          inside_contact.htm 
         
 
      
 
     
   

但是，在本例中 content 参数值不一样的时候，其实根据业务逻辑，不该该算做“冗余页面的”，而按照配置，也会被自动过滤了，遇到这种状况，就须要考虑增长“冗余路径限制”，如设置为 20 或者 50。以能够更屡次访问这些页面。

这些状况常常存在于跳转参数等状况。

顺便备注下，“冗余路径限制”，功能设置的目的是为了处理相似论坛 BBS 等页面，只有文本内容不一样，页面架构彻底相同的页面：如

 
          1 
        
          2 
        
          3 
        
          http: 
          / 
          / 
          www.Test.com 
          / 
          showthread.php? 
          id 
          = 
          1 
         
          http: 
          / 
          / 
          www.Test.com 
          / 
          showthread.php? 
          id 
          = 
          2 
         
          http: 
          / 
          / 
          www.Test.com 
          / 
          showthread.php? 
          id 
          = 
          3

而咱们在测试 demo.testfire.net 时候会发现每次的安全测试结果均可能有差异，一个很大的缘由就是每次访问的页面是不一样的，就是这个设置的影响。

分析重复的“脚本参数”

在上面的步骤中，分析了“伪静态页面”，对其应该经过“排除路径或者文件名”的方法设置排除规则；而对于“业务类型的冗余路径”，则须要经过增长“冗余路径显示”个数等的方法进行扩充，以扫描到这些 URL。咱们在这个步骤来分析另一种参数，脚本参数。

在“个人应用程序数据”树状结构下，鼠标选择目录之后，在右边视图中选择“脚本参数”，而后查看是否存在不一样页面（URL) 存在相同或者相似参数的状况：以下图，在不一样 URL 中，都存在 kbKey 参数，默认的参数值是“请输入您要搜索的问题”：

访问这些 URL，发现每一个页面内都包含了一个搜索功能，这就是为何在不一样页面都发现了该参数。而从业务角度，这些搜索页面在一个 URL 中进行测试之后，没有必要在另一个页面也进行测试。并且该参数值的变化，能够认为是冗余页面，没有必要进行下一步的从新探索和测试。这能够经过上图中，选择该参数后，鼠标右键，选择“添加到‘参数和 Cookie’选项卡中的列表”来实现。选择后弹出下面的页面：

在该页面中，点击“其余选项－冗余调整”，取消选择任何一个选择框，则表示不管是否含有该参数，不管该参数值是否发生变化，都不认为是新页面，没有必要从新测试，并且不该该由于该参数的变化去影响其余参数的测试。

咱们知道，AppScan 中的测试，是针对页面的每一个参数进行的，并且一个参数值的变化会要求从新测试其余的参数，因此该设置，能够大大减小测试用例数。

 
          1 
        
          2 
        
          3 
        
          4 
        
          5 
        
          6 
        
          7 
        
          8 
        
          9 
        
          10 
        
          11 
        
          12 
        
          13 
        
          14 
        
          15 
        
          16 
        
          17 
        
          18 
        
          19 
        
          20 
        
          选框   　　　　　　　　　　　　　　　　　　　　　　　　选中时 ... 
         
          只要添加或除去此参数  
          / 
          cookie，便再次探索 URL。   　在探索阶段，若是两个 URL 的惟一区别在于一个包括此参数，而另外一个不包括此参数，那么将其视为不一样 URL，而且对二者都进行探索。 
         
          　　　　　　　　　　　　　　　　　　　　　　　　　　　　　例如，若是是如下两个 URL，二者都将进行探索： 
         
          　　　　　　　　　　　　　　　　　　　　　　　　　　　　　...page.jsp 
         
          　　　　　　　　　　　　　　　　　　　　　　　　　　　　　...page.jsp?thisParam 
          = 
          Value 
         
          　　　　　　　　　　　　　　　　　　　　　　　　　　　　　若是您取消选中此复选框，那么在此状况下，将仅发送一个请求，而其余请求将被废弃。 
         
          只要此参数  
          / 
          cookie 的值更改，便再次探索 URL。   　在探索阶段，若是两个 URL 的惟一区别在于此参数  
          / 
          cookie 的值，那么将其视为不一样 URL，而且对二者都进行探索。 
         
          　　　　　　　　　　　　　　　　　　　　　　　　　　　　　例如，若是是如下两个 URL，二者都将进行探索： 
         
          　　　　　　　　　　　　　　　　　　　　　　　　　　　　　...page.jsp?thisParam 
          = 
          Value1 
         
          　　　　　　　　　　　　　　　　　　　　　　　　　　　　　...page.jsp?thisParam 
          = 
          Value2 
         
          　　　　　　　　　　　　　　　　　　　　　　　　　　　　　若是您取消选中此复选框，那么在此状况下，将仅发送一个请求，而其余请求将被废弃。 
         
          只要添加或除去此参数  
          / 
          cookie，便重复全部相邻参数 　　 　在测试阶段，若是两个 URL 的惟一区别在已添加或除去了此参数，那么将其视为不一样 URL，而且再次测试相邻参数。 
         
          / 
          cookie测试　　　　　　　　　　　　　　　　　　　　　　例如，若是是如下两个 URL，将为相邻参数生成两组完整的测试，每一个 URL 一组。 
         
          　　　　　　　　　　　　　　　　　　　　　　　　　　　　　...page.jsp?adjacentParam 
          = 
          <test_this> 
         
          　　　　　　　　　　　　　　　　　　　　　　　　　　　　　...page.jsp?adjacentParam 
          = 
          <test_this>&thisParam 
          = 
          Value 
         
          　　　　　　　　　　　　　　　　　　　　　　　　　　　　　若是您取消选中此复选框，将为相邻参数仅生成一组测试。 
         
          只要此参数  
          / 
          cookie 的值更改，便重复全部相邻参数      在测试阶段，若是两个 URL 的惟一区别在于此参数  
          / 
          cookie 的值，那么将其视为不一样 URL，而且再次测试相邻参数。 
         
          / 
          cookie测试　　　　　　　　　　　　　　　　　　　　　　　例如，若是是如下两个 URL，将为相邻参数生成两组完整的测试，每一个 URL 一组。 
         
          　　　　　　　　　　　　　　　　　　　　　　　　　　      ...page.jsp?adjacentParam 
          = 
          <test_this>&thisParam 
          = 
          Value1 
         
          　　　　　　　　　　　　　　　　　　　　　　　　　　　   ...page.jsp?adjacentParam 
          = 
          <test_this>&thisParam 
          = 
          Value2 若是您取消选中此复选框，将为相邻参数仅生成一组测试。

查看每一个目录页面个数

若是一个扫描任务，自己的已访问 URL 数超过 5000，评估的要运行的安全测试用例数超过 20，000，则建议进行扫描配置的分析，并根据分析结果，决定是否须要进一步的任务分解和分工。

咱们在“个人应用程序数据”树状结构下，鼠标选择目录之后，在右边视图中选择“已访问的 URL()”，记录 URL 数目，若是该目录 URL 数目比较大（超过 500）则能够考虑为该目录单独创建一个扫描任务，只扫描该目录下面的连接。

执行阶段

根据在“计划阶段”肯定的扫描策略，和进行的扫描设置，从新进行探索（扫描菜单依次选择：从新扫描 - 从新探索）；后继续分析页面数和测试用例数目，若是控制页面数 5000 个之内，测试用例数 20，000 个之内，则能够直接进行扫描；若是没有，建议继续分析，优化扫描配置。

分阶段测试

AppScan 的扫描过程分为“探索”和“测试”两个阶段，默认状况下，使用的是彻底扫描模式，便是边探索边测试的。若是网站比较大，建议考虑先探索后测试的模式。

如当 URL 达到 5000，须要进行的测试达到 50000 的时候，能够暂停扫描，手工中止探索，选择“继续仅测试”。对已经发现和分析的页面进行测试，测试完毕，再来选择“继续仅探索”，即：

继续仅探索 --- 继续仅测试—继续仅探索 - 仅测试的一个循环过程。

在这个过程，一个阶段结束之后，建议查看下 .Scan 文件的大小，若是大小超过了 500M，则建议考虑任务分解，能够根据目录把一个扫描任务分解为多个，或者根据扫描策略来进行分解。

该方法是利用了 AppScan 扫描过程当中，探索测试能够分离，并且支持扫描过程当中断后继续扫描的特性。

按照业务分解扫描任务

在实际工做中，咱们扫描的一个大型网站，每每包含多个频道，而每一个频道可能须要的扫描配置都不一样，这些配置甚至互相冲突。如一个网站的提供了 BBS 论坛功能：

 
      
       
        
           1 
         

           2 
         
 
         
           http: 
           / 
           / 
           www.Test.com 
           / 
           WWW.TEST.COM 
           / 
           showthread?channel 
           = 
           1 
           &thread 
           = 
           1001 
          
 
           http: 
           / 
           / 
           www.Test.com 
           / 
           WWW.TEST.COM 
           / 
           showthread?channel 
           = 
           30 
           &thread 
           = 
           2001 
          
 
       
 
      
    

对于这样的页面，访问后发现页面结构相同，只是文本内容不一样，则应该使用“冗余路径限制”参数，控制扫描次数，没有必要屡次扫描。

同时，该网站的一个服务频道存在以下的页面：

 
           1 
         
           2 
         
           http: 
           / 
           / 
           www.Test.com 
           / 
           default.aspx?content 
           = 
           inside_executives.htm 
          
           http: 
           / 
           / 
           www.Test.com 
           / 
           default.aspx?content 
           = 
           privacy.htm

即上面提到的业务类型的“冗余路径”，应该屡次扫描，配置上要求增大“冗余路径限制”参数。

在这种状况下，就颇有必要根据业务分别创建扫描任务，每一个任务采用不一样的扫描配置。

检查阶段

在扫描执行过程当中，须要检查，看是否存在下面的状况：

提示网络链接不上，或者提示部分页面没法打开。则检查是不是扫描速度过快，服务器不能承受不了，根据状况修改扫描配置 - 链接 - 通讯和代理，增长“超时”数，并考虑减小“并发线程数”，以容许更长时间的等待页面影响并减小对服务器的访问链接数。
发现扫描出的安全问题，包含咱们不关心的安全隐患，则取消掉这些规则。如发现了一个安全隐患，类型是“SQL 注入文件写入（须要用户验证）”，该问题是须要用户根据提示来检查的，而且是针对 SQL 数据库的，若是咱们使用的数据库不是 SQL 数据库，或用户确认后没有发现线索，则就能够在扫描配置 - 测试 - 测试策略中取消选择该策略。
执行“计划阶段”的检查，看是否还存在“伪静态页面”，“业务类型的冗余路径”等，若是存在，则调整扫描配置。

分析阶段

在分析阶段，结合业务特色，检查是否扫描范围，分析扫描结果，并针对扫描出来的问题，进行分析，产生多种类型的报告等。

扫描结果检查

扫描结束后，建议切换到“应用程序数据”视图中，对页面进行分析，检查是否核心页面都被测试到了。重点检查以下部分：

交互式 URL：一些页面，必须输入正确的信息，才能够跳转到下一个页面，好比查询手机欠费的页面，必须输入正确的 11 位手机号码；查询身份信息的页面，必须输入 18 位的身份证号才能够进入后续页面。若是没有配置，AppScan 怎么知道输入这些信息？因此若是存在“交互式”URL，能够选择该 URL 之后，鼠标右键，选择手动探索，在 AppScan 浏览器中访问这些页面，输入对应的数据，则 AppScan 会自动记录这些输入，并填充到扫描配置 - 自动表单填充中。
中断连接：看哪些页面在扫描过程当中，访问出错或者没法访问，如针对 time out 的页面，就多是由于网络缘由，扫描过程当中没有及时响应，能够选择“重试全部中断连接”从新进行访问。

报告分析

咱们须要对报告进行对比分析或者报告汇总合并，方法以下：

增量分析：在实际工做中，常常对一个网站进行按期扫描，那么咱们可使用报告对比功能，对比两次产生的结果，检查哪些问题已经修改，哪些是新发现的安全隐患。方法是选择报告 - 增量分析。
报告汇总和合并：而若是咱们在执行阶段，按照业务或者目录进行了分解，最后可能须要对多份扫描结果进行合并和汇总，合并过程当中重复的问题只记录一次，如扫描任务 A 和任务 B 都发现了 apply.jsp 的 ID 参数存在 XSS 安全隐患，则合并后只记录一次。报告的合并须要使用到 AppScan 企业版，其具备 AppScan 标准版的扫描功能和强大的报告汇总功能，能够产生仪表盘，报告的对比分析，趋势分析等。能够把 AppScan 标准版的报告发布到 AppScan 企业版中，方法是菜单栏中依次选择文件 - 导出 - 将结果发布到 AppScan Enterprise。

案例分析

工做中遇到一个案例，使用 AppScan 扫描扫描了 3*24 小时，扫描的 scan 文件已经达到 9G；扫描还在持续进行中，整体进度完成了 30%，能够想象扫描速度已经很缓慢，还须要多长时间才能够完成扫描？扫描完成之后如此大的结果文件是否能够成功打开和修改保存 ?

按照个人经验，若是扫描结果文件大于 1G，那就颇有必要当即中止扫描，进行配置分析。咱们的分析过程以下：

和用户讨论，确认关心的安全问题，根据这些安全问题制定测试策略；讨论后肯定选择“SQL 注入”和“跨站点脚本编制”两种类型的安全隐患。
肯定网站范围，被扫描应用是典型运营商门户网站，重点要扫描门户网站自身和其上面提供的“网上营业厅”服务。
分析被测网站，使用 AppScan 配置了网站主页面，而后选择“仅探索”运行 20 分钟后，发现 30，000 多个页面。中止探索，开始分析页面。
分析发现该网站同一个连接，存在 http、https 访问的不一样状况，并且两种访问方式访问到的页面内容相同，则过滤掉 https 的请求，集中测试 http 请求。
分析发现存在大量的“伪静态页面”，如：

 
          1 
        
          2 
        
          http: 
          / 
          / 
          www.Test.com 
          / 
          / 
          focus 
          / 
          satisfy 
          / 
          file5.html 
         
          http: 
          / 
          / 
          www.Test.com 
          / 
          / 
          focus 
          / 
          satisfy 
          / 
          file6.html

　　在扫描配置 - 排除路径和文件中：

　　排除全部该类型的页面；.*file\d+.html

　　增长“例外”，对该类型的页面只扫描 file1.html 和 file20.html

　　6.同时，发现了 swf 文件，应该不许备扫描 Flash，因此在“排除文件类型”中，设置根据后缀名排除 swf 文件。

　　7.发现

 
          1 
        
          http: 
          / 
          / 
          www.Test.com 
          / 
          service

目录下存在大量以下类型的页面，都是 menu 参数值不一样，访问之后发现出现的是页面中有不一样的超连接：　

 
     
      
       
          1 
        

          2 
        

          3 
        
 
        
          http: 
          / 
          / 
          www.Test.com 
          / 
          service 
          / 
          Business.do?menu 
          = 
          Query 
         
 
          http: 
          / 
          / 
          www.Test.com 
          / 
          service 
          / 
          Business.do?menu 
          = 
          Open 
         
 
          http: 
          / 
          / 
          www.Test.com 
          / 
          service 
          / 
          Business.do?menu 
          = 
          Service 
         
 
      
 
     
   

　　确认该页面是业务类型的“冗余路径”，应该全面扫描，则须要把“冗余路径设置”调整为比较大的参数，同时该频道是网上营业厅频道，也要求用户先登陆。因此针对该目录创建一个单独的扫描任务，只扫描该目录和其下子目录。

　　8.分析发现 index.jsp 在多个目录下出现，并且每次出现都有两种格式，即没有参数和有固定的三个参数，每次的参数值都相同。如：

 
     
      
       
          1 
        

          2 
        

          3 
        
 
        
          http: 
          / 
          / 
          www.Test.com 
          / 
          / 
          rdwd 
          / 
          jfmz 
          / 
          jifen 
          / 
          index.htmlhttp: 
          / 
          / 
          www.Test.com 
          / 
          / 
          rdwd 
          / 
          jfmz 
          / 
          jifen 
          / 
          index.html?queryType 
          = 
          common&applyArea 
          = 
          010 
         
 
               
          &kbKey 
          =  
          请输入您要搜索的问题http: 
          / 
          / 
          www.Test.com 
          / 
          / 
          rdwd 
          / 
          txl 
          / 
          rdwdznyd 
          / 
          index.htmlhttp: 
          / 
          / 
          www.Test.com 
          / 
          / 
          rdwd 
          / 
          txl 
          / 
          rdwdznyd 
          / 
          index.html?queryType 
          = 
          common&applyArea 
          = 
          010 
         
 
               
          &kbKey 
          =  
          请输入您要搜索的问题 
         
 
      
 
     
   

访问上面的页面，发现内容相同，则说明是否带这三个参数不会影响探索发现更多的页面，则能够设置这三个参数每次是否出现，是否有不一样值均可以认为是同一个页面。

设置方法：扫描配置中依次选择“参数和 Cookie”来实现。而后增长 queryType，applyArea，kbKey 三个参数，均设置为“是否有参数”、“参数是否变化”不影响测试的模式。

　　9.切换到“应用程序视图”，分析“中断连接”，发现一些页面存在“范围内容超过最大容量的”的状况，在 IE 浏览器中直接访问，发现这些页面存在死循环，页面内容无限递增。则在扫描配置 - 排除路径和文件中排除这些页面。

　　10.根据以上设置，创建了两个扫描任务，均扫描“SQL 注入”和“跨站点脚本编制”。从新探索后，页面总数减小到 4000 多，测试用例数减小到接近 50，000，两个扫描任务均在 8 个小时内完成。