如何有效的使用AppScan扫描大型网站 - 图文

转载]如何更有效使用 Rational AppScan 扫描大型网站

Rational AppScan（简称AppScan）其实是一个产品家族，包括众多的应用安全扫描产品，从开发阶段的源代码扫描的AppScan source edition，到针对 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 文件里面主要包括的内容如下：

a. 扫描配置信息：扫描配置信息，如扫描的目标网站地址，录制的登陆过程脚

本等，选择的扫描设置等都保存在 Scan 文件中。

b. 所有访问到页面信息：针对每个发现的页面，即使没有进行测试，在探索过

程也会访问该页面并纪录 http request/response 信息；所以如果探索的页面访问的时候返回的页面内容比较多，页面比较大，那么即使只做了探索根本没有扫描，整个 Scan 文件也会很大。

c. 测试阶段，记录测试成功的测试变体和页面访问信息：针对每个页面都会发

送多次测试（测试变体），每次测试都会有 Request/response 信息，这些信息如果测试通过，即发现了一个安全问题，则会把该测试变体对应得 request/response 都会纪录下来，保存在 .scan 文件中；由于AppScan的扫描测试用例库全面，对于每种安全威胁漏洞，都会发送多个安全测试变体（Variant）进行测试，比如对于 XSS 问题，AppScan发送了 100 个变体，其中 30 个执行失败，70 个变体执行成功，则会纪录 70 次执行成功的具体变体信息，以及每个变体对应的 Request/Response 信息。这就是一个很大的数据量。这些信息保存以后，就可以在不连接在网站的情况下进行结果分析，快速显示当时测试的页面快照等。

我们以http://demo.testfire.net/bank/customize.aspx为例，如下就有 74 个变体都发现了 Customize 页面的 Lang 参数存在跨站点脚本执行（XSS）类型的安全漏洞：

图 5. 测试变体显示

所以针对AppScan标准版来说，由于需要保存的信息比较多，结果文件是会比较大的，最根本的方法还是有针对性地进行扫描和测试，使用排除页面等排除冗余页面，把一个大的系统分解为多个小的扫描任务等。

好的，了解了AppScan的原理，我们就结合原来讨论下为什么扫描大型网站时候可能遇到问题了。

磁盘空间 30 GB 网络 1 NIC 100 Mbps（具有已配置的 TCP/IP 的网络通信）

其中，处理器和内存建议越大越好，而磁盘空间，建议系统盘（一般是 C 盘）磁盘空间至少保留 10G，如果系统盘磁盘空间比较少，可以考虑把用户文件等保存在其他盘；如默认的用户文件是：C:Documents and SettingsAdministratorMyDocumentsAppScan；可以修改为其他路径。该路径可以在菜单栏中依次选择工具 - 选项 - 一般 - 文件位置部分修改。

图 1. 设置文件保存路径

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

有时候大家会发现，已经把上面的地址都修改到了其他盘，但是在扫描过程中，还是会发现 C 盘的空间快速被消耗，分析原因，是因为很多临时文件都保存在 C 盘，AppScan中有一个隐藏的参数 APPSCAN_TEMP 来设置临时文件位置。在扫描过程中，如果系统盘空间比较下，可以通过修改系统变量来修改到其他硬盘空间。

临时文件位置说明：描述正常操作期间AppScan将其临时文件保存到的位置。缺省情况下，AppScan将其临时文件存储在以下位置：

C:Documents and SettingsAllUsersApplicationDataIBMRationalAppScantemp

如果需要修改此缺省位置，请按照要求编辑环境变量 APPSCAN_TEMP 的路径。（访问环境变量的方法是，右键单击我的电脑，然后依次选择属性>高级>环境变量。）

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

修改AppScan中的临时文件：

1. 桌面上鼠标右键选择“我的电脑”，选择“属性” 2. 选择“高级”，“环境变量”

3. 增加一个新的“用户环境变量”，名字是“APPSCAN_TEMP”，设定路径，指向您希望

保存临时文件的目录。

5. 分组类型，切换到“侵入式”类型，下面有“非侵入式”和“侵入式”两种分类。取消“基

础结构”级别的测试。

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

图 3. 查询测试策略

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

了解被测试网站

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

表 2. 记录被测网站特点

应用系统名访问地URL 数应用系统架构（JEE/.Net/PHP…） 称 址 量

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

那么，如果可以了解到网站具体有哪些页面呢？这里我们就可以利用AppScan的探索（页面爬行）能力。

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

我们一般关心这几个视图：

? 已访问的 URL()：AppScan已经探索到并且进行了分析的页面

? 已过滤掉的 URL()：AppScan已经发现，同时根据扫描配置，认为不需要进行安全

扫描的页面。

? 中断链接 URL()：AppScan发现了，但是无法访问到或者访问出错的页面，如 404

页面不存在，或者 500 服务器错误等。

伪静态页面

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

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

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+ 数字格式的页面，我们就可以设置正则表达式来过滤，比如，在扫描配置 - 排除路径和文件中

排除所有该类型的页面；.*filed+.html

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

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

业务类型的“冗余路径”

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

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认为是冗余页面呢 ?

图 4. 冗余路径设置

简单说：

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

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

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

http://www.Test.com/default.aspx?content=business.htm

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

可是，在本例中 content 参数值不同的时候，其实根据业务逻辑，不应该算作“冗余页面的”，而按照配置，也会被自动过滤了，遇到这种情况，就需要考虑增加“冗余路径限制”，如设置为 20 或者 50。以可以更多次访问这些页面。

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

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

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参数，默认的参数值是“请输入您要搜索的问题”：

图 5. 脚本参数

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

图表 6 添加参数定义（根据参数来设置冗余路径）

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

我们知道，AppScan中的测试，是针对页面的每个参数进行的，而且一个参数值的变化会要求重新测试其他的参数，所以该设置，可以大大减少测试用例数。

关于更多的设置说明，可以参照下面的解释：

表 3. 设置说明

查看每个目录页面个数

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

我们在“我的应用程序数据”树状结构下，鼠标选择目录以后，在右边视图中选择“已访问的 URL()”，记录 URL 数目，如果该目录 URL 数目比较大（超过 500）则可以考虑为该目录单独建立一个扫描任务，只扫描该目录下面的链接。

执行阶段

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

分阶段测试

AppScan的扫描过程分为“探索”和“测试”两个阶段，默认情况下，使用的是完全扫描模式，即是边探索边测试的。如果网站比较大，建议考虑先探索后测试的模式。

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

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

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

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

按照业务分解扫描任务

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

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

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

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

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

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

在这种情况下，就很有必要根据业务分别建立扫描任务，每个任务采用不同的扫描配置。

检查阶段

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

1. 提示网络连接不上，或者提示部分页面无法打开。则检查是否是扫描速度过快，服

务器不能承受不了，根据情况修改扫描配置 - 连接 - 通信和代理，增加“超时”数，并考虑减少“并发线程数”，以允许更长时间的等待页面影响并减少对服务器的访问连接数。

2. 发现扫描出的安全问题，包含我们不关心的安全隐患，则取消掉这些规则。如发现

了一个安全隐患，类型是“SQL 注入文件写入（需要用户验证）”，该问题是需要用户根据提示来检查的，并且是针对 SQL 数据库的，如果我们使用的数据库不是 SQL 数据库，或用户确认后没有发现线索，则就可以在扫描配置 - 测试 - 测试策略中取消选择该策略。

3. 执行“计划阶段”的检查，看是否还存在“伪静态页面”，“业务类型的冗余路径”等，

如果存在，则调整扫描配置。

案例分析

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

按照我的经验，如果扫描结果文件大于 1G，那就很有必要立即停止扫描，进行配置分析。我们的分析过程如下：

1. 和用户讨论，确认关心的安全问题，根据这些安全问题制定测试策略；讨论后确定

选择“SQL 注入”和“跨站点脚本编制”两种类型的安全隐患。

2. 确定网站范围，被扫描应用是典型运营商门户网站，重点要扫描门户网站自身和其

上面提供的“网上营业厅”服务。

3. 分析被测网站，使用AppScan配置了网站主页面，然后选择“仅探索”运行 20 分钟

后，发现 30，000 多个页面。停止探索，开始分析页面。

4. 分析发现该网站同一个链接，存在 http、https 访问的不同情况，而且两种访问方式

访问到的页面内容相同，则过滤掉 https 的请求，集中测试 http 请求。 5. 分析发现存在大量的“伪静态页面”，如：

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

6.

7. 在扫描配置 - 排除路径和文件中： 8. 排除所有该类型的页面；.*filed+.html

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

10. 同时，发现了swf文件，应该不准备扫描 Flash，所以在“排除文件类型”中，设置

根据后缀名排除swf文件。 11. 发现

http://www.Test.com/service

12.

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

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

13.

14. 确认该页面是业务类型的“冗余路径”，应该全面扫描，则需要把“冗余路径设置”

调整为比较大的参数，同时该频道是网上营业厅频道，也要求用户先登录。所以针对该目录建立一个单独的扫描任务，只扫描该目录和其下子目录。

15. 分析发现index.jsp在多个目录下出现，而且每次出现都有两种格式，即没有参数

和有固定的三个参数，每次的参数值都相同。如：

http://www.Test.com//rdwd/jfmz/jifen/index.html

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

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

16.

17. 访问上面的页面，发现内容相同，则说明是否带这三个参数不会影响探索发现更

多的页面，则可以设置这三个参数每次是否出现，是否有不同值都可以认为是同一个页面。

18. 设置方法：扫描配置中依次选择“参数和 Cookie”来实现。然后增加queryType，

applyArea，kbKey三个参数，均设置为“是否有参数”、“参数是否变化”不影响测试的模式。

19. 切换到“应用程序视图”，分析“中断链接”，发现一些页面存在“范围内容超过最大

容量的”的情况，在 IE 浏览器中直接访问，发现这些页面存在死循环，页面内容无限递增。则在扫描配置 - 排除路径和文件中排除这些页面。

20. 根据以上设置，建立了两个扫描任务，均扫描“SQL 注入”和“跨站点脚本编制”。

重新探索后，页面总数减少到 4000 多，测试用例数减少到接近 50，000，两个扫描任务均在 8 个小时内完成。

总结

AppScan作为一种自动化的扫描设置工具，我们了解其工作原理后，需要根据被测系统的业务特点和网站结构特点，优化配置，从而可以快速的针对性扫描。

常用的设置是可以利用其“探索”功能，快速得到结构，然后分析是否存在“伪静态页面”，业务上的“冗余路径”页面，“参数重复”页面等，在扫描配置中对应设置。

同时，如果设置后网站规模还是比较大，则可以根据业务分解为多个扫描任务，从而分而攻之，快速扫描，并结合企业版等工具，综合汇总分析.

在实际工作中，我们也很难在最开始的阶段，就把扫描规范制定下来，按照项目经理们的口头禅“渐进明细”，“滚动式规划”，在实践中，更多时候也是摸着石头过河，选择了一个扫描策略，然后根据结果分析，看是否需要调整，不断优化。比如选择默认的“缺省值”扫描策略，对网站进行扫描，发现其“敏感信息”里面会去检查页面上是否含有 Email 地址，是否含有信用卡号码等，如果我们觉得这些信息，显示在页面上是正常的业务需要（比如这样的链接：

admin@www.test.com），我们就可以取消掉这些规则，所以扫描规则也很大程度上

影响着我们的扫描效率。

网站采用多种混合的技术，需要不同的扫描设置

一些大型网站，往往是一个统一的入口，在里面提供不同的内容，而这些内容可能来源于不同的技术。如我们熟悉的门户网站，里面就有“财经”、“体育”、“娱乐”等多个频道；每个频道的内容，可能是采用不同的技术，对应不同的服务器。如一个网站的“论坛”频道，就有很多类似的页面：

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

这里的showthread.php页面存在多次，每次都是参数值不同，访问后发现这些页面除了文本内容外，其他的页面结构等都相同，则这些页面只需要选择几个典型的扫描即可，没有必要全部扫描。

而同时，在另外的一些频道，存在另外类型的页面：

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

这些动态页面，也是网址相同，参数相同，但是具有不同的参数值，访问时候发现每种类型的参数值都指向了完全不同的页面，则需要每种参数值都要测试到。这种情况经常存在跳转页面中。

而这两个频道中，第一种情况，可以选择典型的页面扫描之，而第二种情况则需要进行完全的扫描，每种参数值都需要考虑到。这就需要不同的扫描设置。

同时，可能大家也注意到了，第一种情况下的是php页面，而第二种情况下的则是aspx页面，对应不同的开发技术，这也可能需要不同的扫描设置。

所以，总结下，AppScan的扫描受到如下因素的影响：

? 网站规模（页面个数，页面参数） ? 扫描策略的选择 ? 扫描设置

而对于大型的网站，我们经常需要从几个方面来优化配置

? 选择合适的，最小化的扫描规则

? 分解扫描任务，把一个大的扫描任务分解为多个小的扫描任务 ? 根据页面特点，设置可以过滤的类似页面（冗余页面）

本文来源：https://www.bwwdw.com/article/mrxp.html