君，已阅读到文档的结尾了呢~~
rational rational rose 扫描仪..
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
Rational AppScan 扫描网站 增强扫描质量篇
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-4.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口查看: 2735|回复: 5
请教问题:appscan生成报告,怎么去手动测试证明有bug?
该用户从未签到
appscan生成报告,看到有一些漏洞,但是我怎么能手动测试去证明有bug?
报告里的代码有些看不太懂.....
[1 / 1]&&检测到应用程序测试脚本 严重性： 低
测试类型： 应用程序
有漏洞的 URL： http://www.**.com/&&
修复任务： 除去服务器中的测试脚本
1 的变体 1&&[ID=1303] 以下更改已应用到原始请求：
• 已将路径设置为“/test.html”
请求/响应： GET /test.html HTTP/1.0
Cookie: ASP.NET_SessionId=y5sdwr55ih0nma55kqkmziaq
Accept: */*
Accept-Language: en-US
User-Agent: Mozilla/4.0 ( MSIE 6.0; Win32)
Host: www.**.com
HTTP/1.1 200 OK
Content-Length: 10
Content-Type: text/html
Last-Modified: Tue, 19 Jun :20 GMT
Accept-Ranges: bytes
ETag: &252d18afd94dcd1:0&
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Mon, 16 Jul :32 GMT
Connection: close
Is Staging 响应中的验证： • HTTP/1.1 200 OK
推理： AppScan 请求的文件可能不是应用程序的合法部分。响应状态为“200 OK”。这表示测试成功检索了所请求的文件的内容。
=======================================
以上只是它的推理吧,我要怎么去测试? 还是要去看源代码?
可以具体点吗?刚刚学.
该用户从未签到
选中任意一个有漏洞的URL,在请求/响应的选项卡下找到“测试”/&原始&，分别对比这两个请求的URL和参数，如果看不出，那么就在此选项卡下点“在浏览器显示”
该用户从未签到
后来其实自己也细细看,就看到了.
人就怕有依赖心理,不仔细.
TA的每日心情奋斗2&小时前签到天数: 47 天连续签到: 1 天[LV.5]测试团长
看这个提示是个低级别的问题
TA的每日心情奋斗2&小时前签到天数: 47 天连续签到: 1 天[LV.5]测试团长
另外那个test.html如果是正常的业务文件这个问题就不是问题了
TA的每日心情无聊 13:02签到天数: 6 天连续签到: 1 天[LV.2]测试排长
站长推荐 /4
小伙伴们踊跃闯关，赢取测试积点，换取豪礼，还等什么，赶快行动吧~
扫描左侧二维码，开启51Testing时光机，回到12年前，共同唤起曾经的感动！
了解自己的心里圈，学习不同的内容，让自己由内而外强大起来！
10年测试经验，负责及参与BBS、IT商城、CMS、AD等几十个web系统的功能及性能测试，负责团队的管理及建设。
Powered byIBM Bluemix
点击按钮，开始云上的开发！
developerWorks 社区
基于参数导航的站点是指仅通过一个 URL，利用该 URL 中参数的不同值实现不同的页面跳转。缺省情况下，Rational AppScan 的冗余路径限制为 5，即 Rational AppScan 默认只测试 5 个结构相同参数值不同的 URL。对于一般站点而言，这样可避免不必要的重复测试。然而，一旦遇到基于参数导航的站点时，Rational AppScan 会因为忽略掉若干URL导致测试覆盖率较低。因此，本文将跟读者详细分析基于参数导航站点的扫描方法，帮助读者提高 Rational AppScan 的使用水平。
, 高级软件工程师, IBM
何健，IBM 高级软件工程师，多年 Java EE 应用设计开发经验，现在 IBM 全球流程优化服务开发实验室从事软件资产的架构设计及应用安全咨询，在 developerWorks 发表过多篇关于 Web 应用安全及检测技术的文章。您可以通过 developerWorks 社区与进行交流。
, 软件工程师, IBM
熊虎，IBM 软件工程师，服务于 IBM 中国软件研发中心全球化部门 , 从事 Rational，Lotus 和 Websphere 产品线的研究工作。您可以通过 developerWorks 社区与进行交流。
下载试用版：
下载更多的 ，并加入 ，参与在线交流。前言基于参数导航的站点是指某类站点通过同一个 URL 实现不同逻辑页面的跳转，这个 URL 中往往包含某个特定参数，后台应用会根据这个参数的值来判断页面跳转逻辑。缺省情况下，常见渗透测试工具为了提高扫描效率，会限制 URL 结构相同、参数值不同的路径的扫描次数。譬如查询结果页面由于数据量较大采用了分页设计，从安全测试角度来说，仅需要测试头两个页面（头两个页面已包含前后页翻页链接）即已足够。对于这类普通站点而言，这种设计避免了不必要的重复测试。然而如果遇到基于参数导航的站点时，参数值不同的 URL 指向的逻辑页面不同，一旦此类 URL 被过滤掉，很多逻辑页面就会被测试工具忽略掉，则会降低渗透测试的覆盖率。测试覆盖率是渗透测试质量好坏的重要指标，笔者在实际工作中看到很多用户因不了解基于参数导航技术，而造成测试质量不高。因此，笔者通过本文跟读者介绍什么是基于参数导航的站点，结合 IBM Rational AppScan Standard（下文简称 AppScan）跟读者分享如何识别基于参数导航的站点，理解 AppScan 关于参数和路径冗余的配置，从而掌握针对基于参数导航站点的安全扫描，帮助读者提高 AppScan 使用水平。什么是基于参数导航的站点参数导航是程序开发人员在开发过程中采用的一种技术。对于渗透测试和测试人员而言，被测试的站点是一个黑盒，我们无法知晓该站点的代码实现方式。因此我们往往通过对爬虫探索出来的 URL 进行人工判断。清单 1 列出三个常见的基于参数导航的站点的 URL，下面我们通过这些直观的 URL 来解释什么是基于参数导航的站点。清单 1. 典型基于参数导航站点的 URL1) http://www.some.site/index.do?action=View&user=John
2) http://www.some.site/index.do?action=Edit&user=John
3) http://www.some.site/index.do?action=Edit&user=Bart非常直观，以上三个 URL 的路径相同，不同点只是参数值不太一样，看上去似乎这几个 URL 是指向同一个网页。但仔细观察后可以看出，1 和 2 的不同点在于参数“action”的属性值不同；2 和 3 的不同点在于参数“user”的属性值不同。根据参数“action”的属性值来看，1 和 2 这两个 URL 分别调用了不同的功能且跳转到不同的网页（一个指向查看用户信息页面，另一个指向修改帐号页面）。2 和 3 这两个 URL 执行的是同一个功能，且跳转到相同的页面（都是指向修改帐号页面）。分析到这里，什么是基于参数导航已经显而易见。这个站点即利用参数“action”实现了不同逻辑页面的导航，参数“action”也就是导航参数。如果读者有 Web 应用开发经验（尤其是具有基于 MVC 框架 Web 应用开发经验者），看到清单 1 中的 URL 会非常熟悉。譬如，Struts1.x 框架提供了 DispatchAction，允许一个 Action 类中包含多个处理逻辑，用户通过不同的请求按钮提交表单时，会调用 Action 中的不同方法来处理请求。这个 Action 类的访问地址往往会是这样：/SomeAction.do?method=methodname。通常 MVC 框架都是通过控制器根据 HTTP 请求内容，寻找出对应的处理逻辑类，调用完处理逻辑类后跳转到指定页面。笔者在实际项目中看到过很多 MVC 框架的常用 URL 为 /ControllServlet?Action=ActionClassName，此类 MVC 框架也是典型的基于参数导航的 Web 应用。理解基于参数导航的概念后，我们重新回到渗透测试的角度来看待清单 1 中的几个 URL。为了提高测试覆盖率，我们必须要扫描第一个和第二个 URL；为了提升测试效率，我们不希望扫描第三个 URL，因为前文已经介绍，第三个 URL 跟第二个 URL 指向的是相同的功能页面。因此，对于安全测试人员而言，摆在我们面前的有两个问题：一是要识别出当前站点是否采用了参数导航技术；二是要通过配置让测试工具仅测试导航参数值不同的 URL，不测试导航参数值相同的 URL（导航参数值不同，即表示 URL 指向了不同的功能和页面，如清单 1 中 1 和 2 两个 URL 所示；导航参数值相同即表示 URL 指向了相同的功能和页面，如清单 2 中 2 和 3 两个 URL 所示）。下文笔者将介绍如何基于 AppScan 分析以上两个问题。识别基于参数导航的站点使用过 AppScan 的读者应该知道，AppScan 的扫描分为探索阶段和测试阶段。AppScan 在探索阶段会利用爬虫技术探索应用站点。它通过模拟 Web 用户单击链接并填写表单字段发送请求，记录请求的响应，并分析所发送的每个请求的响应，基于对响应的安全隐患分析结果创建相应的测试变体。探索阶段完成时，AppScan 会创建出应用站点的 URL、目录和文件等的层次结构树，显示在应用程序树中。AppScan 在测试阶段将发送在探索阶段创建的数千个测试变体，基于规则验证是否存在安全漏洞。为了提高测试的覆盖率，我们建议在探索阶段完成后，要对探索结果进行细致分析，其中一项重要的分析工作就是识别是否存在基于参数的导航。探索结果确认合格后，再进入测试阶段。图 1. 应用程序数据视图如图 1 所示，在探索完成后，我们建议打开“应用程序数据视图”，选择查看“已过滤的 URL”。通常来说，有“文件扩展名过滤”、“未测试的 Web Server”和“路径限制”三类被过滤的 URL。顾名思义，“文件名扩展过滤”指的是 URL 因指向某类被排除扫描的文件而被过滤（参见“扫描配置”-“排除路径和文件”-“排除文件类型”设置）；“未测试的 Web Server”指的是 URL 的域名不在指定的测试服务器和域列表内而被过滤（如果需要扫描这些 URL，则需要在“扫描配置”-“URL 和服务器”-“其他服务器和域”中添加对应的域名）；“路径限制”指的是某类结构相同的 URL 已被探索过，后续被忽略的相同结构的 URL。我们需要仔细分析这些被“路径限制”过滤的 URL 清单，检查 URL 中是否存在作为导航的参数。检查方法主要是基于经验判断，结合手工执行这些 URL 查看响应进行人工判断，找出其中的导航参数。条件允许的话，建议邀请应用开发人员帮助验证，这样准确度会更高。找到导航参数后，我们需要设置 AppScan 的扫描配置，让 AppScan 在探索和测试阶段自动识别出基于参数导航的 URL。在介绍这些扫描配置前，我们先熟悉一下 AppScan 的两个重要配置项：“冗余路径限制”和“参数冗余调整”。掌握这两个配置项后，我们自然就水到渠成地掌握基于参数导航站点的扫描方法。理解 AppScan 的冗余路径和参数冗余设置如前文所述，渗透测试工具为了提高效率通常会限制相同路径的扫描次数，避免重复性测试。AppScan 的这个配置项叫做“冗余路径限制”，点击“扫描配置”，进入“探索选项”，即能看到“冗余路径限制”配置，如图 2 所示。图 2. 冗余路径限制“冗余路径限制”定义了相同路径的最大访问次数（默认 5 次）。当达到这个次数后，AppScan 再次探索到这个路径时会过滤掉这个路径。值得注意的是，这里说的路径并没有考虑 URL 的参数结构，譬如清单 2 中所示的 3 个 URL 都被 AppScan 视为相同的路径，当 AppScan 探索到 index.do?* 达到 5 次后，将忽略其他 index.do 的 URL，即便新 URL 的参数结构跟之前探索到的 5 条 URL 完全不同。清单 2. 典型基于参数导航站点的 URL1) http://www.some.site/index.do
2) http://www.some.site/index.do?action=New
3) http://www.some.site/index.do?action=View&user=John理解“冗余路径限制”后，我们明白这个配置项有利于优化扫描性能。因此对于非参数导航的站点，这个参数值要设置得低一些。但对于基于参数导航的站点，我们建议禁止冗余路径或者将该配置项设置到 500 以上。读到这里，读者可能会疑惑，如果将“冗余路径限制”禁用或设置到 500 以上，AppScan 一旦探索到查询结果页面（包括查看详情的链接）时，岂不是会执行非常多的重复性扫描，这对性能岂不是造成很大影响。非常好的问题，这也就引出了 AppScan 的另一个非常重要的配置项“参数冗余调整”。点击“扫描配置”-“参数和 cookie”，双击某个参数即可查看到该参数的冗余调整设置；在“参数和 cookie”对话框中可点击“冗余调整缺省值”查看和修改默认参数冗余配置。图 3. 参数冗余调整缺省值“参数冗余调整”便于我们区分有导航作用的参数和普通的参数。通过细致的冗余调整，AppScan 能够识别并测试导航参数（譬如清单 1 中的“action”参数），忽略不重要的普通参数（譬如清单 1 中的“user”参数）。下面我们将详细介绍“参数冗余调整”的各个选项及作用。只要添加或除去此参数 /cookie，便再次探索 URL在探索阶段，如果两个 URL 的唯一区别在于一个包括此参数，而另一个不包括此参数，那么将其视为不同 URL，并且对两者都进行探索。只要此参数 /cookie 的值更改，便再次探索 URL在探索阶段，如果两个 URL 的唯一区别在于此参数 /cookie 的值，那么将其视为不同 URL，并且对两者都进行探索。只要添加或除去此参数 /cookie，便重复所有相邻参数 /cookie 测试在测试阶段，如果两个 URL 的唯一区别在已添加或除去了此参数，那么将其视为不同 URL，并且再次测试相邻参数。只要此参数 /cookie 的值更改，便重复所有相邻参数 /cookie 测试在测试阶段，如果两个 URL 的唯一区别在于此参数 /cookie 的值，那么将其视为不同 URL，并且再次测试相邻参数。缺省情况下，上面前三个选项默认启用，最后一个选项没有启用。基于以上“参数冗余调整”的认识，我们就能找到前面所提问题的解决办法，即禁用“冗余路径限制”或将其属性值设置为大于 500 后，如何防止 AppScan 重复性测试导致性能低下。我们可以设置缺省参数冗余：禁用“只要此参数 /cookie 的值更改，便再次探索 URL”。譬如 AppScan 探索过程中遇见翻页一类的 URL，参数“pageNumber”的值发生变化，AppScan 便不会再次探索此类 URL，保证了 AppScan 扫描的良好性能；同时我们在“参数和 cookie”对话框中增加导航参数的定义，同时修改导航参数的“参数冗余调整”，启用上文所提的全部四个参数冗余调整选项。如图 4 所示，我们新建导航参数“action”，一旦“action”的值发生变化，AppScan 会再次探索 URL，且测试阶段，一旦 action 的值发生变化，AppScan 会对其相邻参数进行测试，保证了测试的高覆盖率。图 4. 导航参数定义扫描基于参数导航的站点上文已经介绍了什么是参数导航的站点，如何通过 AppScan 识别当前站点是否有参数导航，并介绍了 AppScan 的两个重要配置项“冗余路径限制”及“参数冗余调整”，同时解释了如何针对基于参数导航的站点，调整这两个扫描参数设置。事实上如图 5 所示，AppScan 为了帮助用户扫描基于参数导航的站点，内置了预定义模板“基于参数的导航”。下文将总结基于参数的导航模板及使用方法。图 5. 基于参数的导航模板基于参数的导航模板主要针对基于参数导航的站点调整了以下几项设置：冗余路径限制 - 将默认值从 5 修改为 500参数冗余调整缺省项 - 启用“只要添加或除去此参数 /cookie，便再次探索 URL”和“只要添加或除去此参数 /cookie，便重复所有相邻参数 /cookie 测试”新增一个参数 - 参数形式为正则表达式，用以识别常见用作导航的参数，同时启用全部冗余调整选项。注意：参数名称正则表达式为“
.*(?i)(page|redirect|content|target|EVENTTARGET|EVENTARGUMENT|goto|node|action|ctrl|source.*”如果实际项目中的导航参数名称不在其中，则需要将实际导航参数名称添加到这个正则表达式中。下文本文将结合案例跟读者演示如何使用基于参数的导航模板。案例笔者基于 Struct1.x 编写了一个简单的测试站点，如图 6 所示。页面中共有六个按钮，URL 是“/UserAction.do?method=*”，参数“method”是导航参数，点击不同按钮会根据“method”属性值去调用 UserAction 类中的对应方法。显然，这六个按钮跳转到不同的逻辑功能，我们应该测试这全部六个按钮的 URL。六个按钮下方列出了九个用户，查看用户的 URL 是“/UserAction.do?method=display&name=*”，点击用户链接会分别打印各个用户的名字。显然，我们仅需要测试这九个用户的其中一个的 URL 即可。图 6. DEMO 应用主界面下面我们将基于“常规扫描”和“基于参数的导航”两个模板分别探索这个应用，比较一下这两种配置下 AppScan 探索结果的区别，便于读者直观认识“基于参数的导航”的应用场景和使用方法。基于“常规扫描”模板的探索利用向导新建 Web 应用程序扫描。点击“文件”-“新建”，选择“常规扫描”模板，在弹出的向导对话框中选择“Web 应用程序扫描”。输入起始 URL“”（笔者本地的应用，读者需将 URL 更新为自己本地域名），登录方式选择“无”，测试策略选择“开发者精要”，选择“仅适用自动‘探索’启动”，启动自动探索。探索完成后进入“应用程序数据”视图，查看探索结果，如图 7、图 8 所示。图 7. 常规扫描之已访问的 URL图 8. 常规扫描之已过滤的 URL可以看出，AppScan 仅访问了五条 UserAction.do 的 URL。“Add”按钮的 URL 被错误过滤掉了，九个用户查看的 URL 也全部被过滤掉了。因此，基于“常规扫描”模板来探索基于参数导航的站点，AppScan 会过滤掉一些本应该扫描的 URL，导致测试覆盖率降低。基于“基于参数的导航”模板的探索下面我们基于“基于参数的导航”模板重新探索笔者搭建的测试应用。利用向导新建 Web 应用程序扫描。点击“文件”-“新建”，选择“基于参数的导航”模板，在弹出的向导对话框中选择“Web 应用程序扫描”。输入起始 URL“”，登录方式选择“无”，测试策略选择“开发者精要”，然后点击下一步。点击“扫描配置向导”对话框左下角的“完全扫描配置”，点击“参数和 cookie”，找到模板内置的导航参数，双击该参数，将“method”增加到参数名称中，修改为“.*(?i)(page|redirect|target|EVENTTARGET|EVENTARGUMENT|goto|node|action|ctrl|source|cmd|path|\btab\b|view|method).*”。选择“仅适用自动”探索“启动”，启动自动探索。探索完成后进入“应用程序数据”视图查看已访问的 URL。图 9. 基于参数的导航扫描之已访问的 URL可以看出，采用“基于参数的导航”模板后，AppScan 正确识别了测试站点的全部六个按钮的 URL，以及其中一个用户查看 URL。这样既保证了测试覆盖率，又避免了不必要的重复性测试，完美解决了前文提出的两个问题。因此，在实际项目中，建议读者在探索完成后，应分析“应用程序数据”视图中的“已过滤的 URL”，检查是否有参数导航的 URL，有的话，建议采用“基于参数的导航”模板进行扫描，按照本文案例中的提示重新完成探索，确认探索结果无误后，点击“扫描”-“仅测试”完成安全渗透测试。总结渗透测试的时候覆盖率是非常重要的质量参数。很多 Rational AppScan 用户没有认识到基于参数导航站点的特殊性，他们采用了常规扫描，结果导致很多 URL 被 AppScan 错误过滤掉。本文旨在向读者介绍什么是基于参数导航的站点，如何识别基于参数导航的站点。同时笔者结合自己的实战经验，跟读者分享了 AppScan 的“冗余路径限制”和“参数冗余调整"两个重要配置的机制和配置建议，最后结合案例向读者演示了常规扫描基于参数导航站点的错误，以及正确使用 AppScan 扫描基于参数导航站点的推荐实践，希望能帮助读者进一步提升 AppScan 的使用水平。鉴于笔者经验有限，若有不及之处，欢迎读者来信交流。
下载描述名字大小本文示例脚本2,330 KB
参考资料 查看文章”，了解 Rational AppScan Standard 的基本使用。查看文章“”，了解关于参数导航站点扫描的常见问答。参考 ，了解 IBM 发布的最新因特网威胁趋势及应对威胁的建议。访问 ，获得关于 IBM Rational 软件交付平台（Rational Software Delivery Platform）产品的技术资源和最佳实践。订阅 ，一份关于 developerWorks 指南、文章、下载、社区活动、网络广播和技术讲座的电子周刊。参考 Rational AppScan，查看 IBM Rational AppScan 产品介绍及文档库。获取免费的 ，了解最新的 IBM Rational 软件开发工具技术文档和资源。下载免费的 。下载更多免费的 ，了解 IBM Rational 软件的最新特性。获取更多 ，并熟练掌握来自 DB2®、Lotus®、Tivoli®，以及 WebSphere® 的开发工具和中间件产品，用这些试用版软件开发您的下一个项目。这些试用版软件可以免费直接从 developerWorks 下载。加入 ，developerWorks 社区是一个面向全球 IT 专业人员，可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区。访问 developerWorks 社区上的 ，这里汇集了丰富的 Jazz 平台中文技术资源。 您可以通过这里了解更多关于 Jazz 平台和 Jazz 技术发展趋势的最新信息。访问 developerWorks 社区上的 ，在那里您将有机会与更多的开发人员一起交流敏捷开发最佳实践。加入 ，参与在线交流。
developerWorks: 登录
标有星（*）号的字段是必填字段。
保持登录。
单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件。
在您首次登录 developerWorks 时，会为您创建一份个人概要。您的个人概要中的信息（您的姓名、国家/地区，以及公司名称）是公开显示的，而且会随着您发布的任何内容一起显示，除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。
所有提交的信息确保安全。
选择您的昵称
当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。昵称长度在 3 至 31 个字符之间。
您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。
标有星（*）号的字段是必填字段。
(昵称长度在 3 至 31 个字符之间)
单击提交则表示您同意developerWorks 的条款和条件。 .
所有提交的信息确保安全。
文章、教程、演示，帮助您构建、部署和管理云应用。
立即加入来自 IBM 的专业 IT 社交网络。
为灾难恢复构建应用，赢取现金大奖。
static.content.url=/developerworks/js/artrating/SITE_ID=10Zone=RationalArticleID=823376ArticleTitle=使用 Rational AppScan 扫描基于参数导航的站点publish-date=Posts - 253,
Articles - 1,
Comments - 1919
大人不华，君子务实。
独立博客：
22:36 by 虫师, ... 阅读,
　　安全测试应该是测试中非常重要的一部分，但他常常最容易被忽视掉。
　　尽管国内经常出现各种安全事件，但没有真正的引起人们的注意。不管是开发还是测试都不太关注产品的安全。当然，这也不能怪我们苦B的&民工兄弟&。因为公司的所给我们的时间与精力只要求我们对产品的功能的实现以及保证功能的正常运行。一方面出于侥幸心理。谁没事会攻击我？
& & &关于安全测试方面的资料也很少，很多人所知道的就是一本书，一个工具。
　　一本书值《web安全测试》，这应该是安全测试领域维数不多又被大家熟知的安全测试书，我曾看过前面几个章节，唉，鄙视一下自己，做事总喜欢虎头蛇尾。写得非常好，介绍了许多安全方面的工具和知识。我觉得就算你不去做专业的安全开发\测试人员。起码可以开阔你的视野，使你在做开发或测试时能够考虑到产品安全方面的设计。防患于未然总是好的，如果你想成为一个优秀的人。
　　一个工具，其实本文也只是想介绍一下，这个工具----AappScan，IBM的这个web安全扫描工具被许多人熟知，相关资料也很多，因为我也摸了摸它的皮毛，所以也来人说两句，呵呵！说起sappScan，对它也颇有些感情，因为，上一份工作的时候，我摸过于测试相关的许多工具，AappScan是其它一个，当时就觉得这工具这么强大，而且还这么傻瓜！！^_^! 于是，后面在面试的简历上写了这个工具，应聘现在的这家公司，几轮面试下来都问到过这个工具，因为现在这家公司一直在使用这个工具做安全方面的扫描。我想能来这家公司和我熟悉AappScan应该有一点点的关系吧！呵呵
AappScan下载与安装
IBM官方下载;
& & 本连接为7.8 简体中文版本的
破解补丁；
& & &破解补丁中有相应的注册机与破解步骤，生成注册码做一下替换就OK了，这里不细说。
　　AppScan其实是一个产品家族，包括众多的应用安全扫描产品，从开发阶段的源代码扫描的AppScan source edition,到针对WEB应用进行快速扫描的AppScan standard edition.以及进行安全管理和汇总整合的AppScan enterprise Edition等，我们经常说的AppScan就是指的桌面版本的AppScan,即AppScan standard edition.其安装在Windows操作系统上，可以对网站等WEB应用进行自动化的应用安全扫描和测试。
使用AppScan来进行扫描
我们按照PDCA的方法论来进行规划和讨论； 建议的AppScan使用步骤：PDCA: Plan,Do,check, Action and Analysis.
计划阶段：明确目的，进行策略性的选择和任务分解。
1)&&明确目的：选择合适的扫描策略
2)&&了解对象：首先进行探索，了解网站结构和规模
3)&&确定策略：进行对应的配置
a)&&&按照目录进行扫描任务的分解
b)&&&按照扫描策略进行扫描任务的分解
执行阶段：一边扫描一遍观察
4)&&进行扫描
5)&&先爬后扫（继续仅测试）
检查阶段（Check）
6)&&检查和调整配置
结果分析(Analysis)
7)&&对比结果
8)&&汇总结果（整合和过滤）
AppScan的工作原理
　　当我们单击&扫描&下面的小三角，可以出现如下的三个选型&继续完全扫描&，&继续仅探索&，&继续仅测试&，有木有？什么意思？ 理解了这个地方，就理解了AppScan的工作原理，我们慢慢展开：
还没有正式开始，所以先不管&继续&，直接来讨论&完全扫描&，&仅探索&，&仅测试&三个名词：　
　　AppScan是对网站等WEB应用进行安全攻击，通过真刀真枪的攻击，来检查网站是否存在安全漏洞；既然是攻击，肯定要有明确的攻击对象吧，比如北约现在的对象就是卡扎菲上校还有他的军队。对网站来说，一个网站存在的页面，可能成千上万。每个页面也都可能存在多个字段（参数），比如一个登陆界面，至少要输入用户名和密码吧，这就是一个页面存在两个字段，你提交了用户名密码等登陆信息，网站总要有地方接受并且检查是否正确吧，这就可能存在一个新的检查页面。这里的每个页面的每个参数都可能存在安全漏洞，所有都是被攻击对象，都需要来检查。
　　这就存在一个问题，你领命来检查一个网站的安全性，这个网站有多少个页面，有多少个参数，页面之间如何跳转，你可能很不明确，如何知道这些信息？ 看起来很复杂，盘根错节；那就更需要找到那个线索，提纲挈领； 那就想一想，访问一个网站的时候，我们需要知道的最重要的信息是哪个？网站主页地址吧？ 从网站地址开始，很多其他频道，其他页面都可以链接过去，对不对，那么可不可以有种技术，告诉了它网站的入口地址，然后它&顺藤摸瓜&，找出其他的网页和页面参数？&OK,这就是&爬虫&&技术，具体说，是&网站爬虫&，其利用了网页的请求都是用http协议发送的，发送和返回的内容都是统一的语言HTML,那么对HTML语言进行分析，找到里面的参数和链接，纪录并继续发送之，最终，找到了这个网站的众多的页面和目录。这个能力AppScan就提供了，这里的术语叫&探索&，explorer，就是去发现，去分析，了解未知的，记录。
　　在使用AppScan的时候，要配置的第一个就是要检查的网站的地址，配置了以后，AppScan就会利用&探索&技术去发现这个网站存在多少个目录，多少个页面，页面中有哪些参数等，简单说，了解了你的网站的结构。
　　&探索&了解了，测试的目标和范围就大致确定了，然后呢，利用&军火库&，发送导弹，进行安全攻击，这个过程就是&测试&；针对发现的每个页面的每个参数，进行安全检查，检查的弹药就来自AppScan的扫描规则库，其类似杀毒软件的病毒库，具体可以检查的安全攻击类型都在里面做好了，我们去使用即可。
　　那么什么是&完全测试呢&，完全测试就是把上面的两个步骤整合起来，&探索&+&&测试&；在安全测试过程中，可以先只进行探索，不进行测试，目的是了解被测的网站结构，评估范围； 然后选择&继续仅测试&，只对前面探索过的页面进行测试，不对新发现的页面进行测试。&完全测试&就是把两个步骤结合在一起，一边探索，一边测试。
上图更容易理解：
步骤1：探索（爬行，爬网）
步骤2：真对找到的页面进行测试，生成安全攻击
AppScan扫描大型网站
　　经常有客户抱怨，说AppScan无法扫描大型的网站，或者是扫描接近完成时候无法保存，甚至保存后的结果文件下次无法打开?；同时大家又都很奇怪，作为一款业界出名的工具，如此的脆弱？是配置使用不当还是自己不太了解呢？我们今天就一起来讨论下AppScan扫描大型网站会遇到的问题以及应对。
　　什么叫大型网站，顾名思义，网站规模大，具体说是页面很多，内容很全。比如,比如，都包括上万个页面。而且除了这个，可能还有一个特点---页面参数多，即要填写的地方多，和用户的交互多；比如一个网站如果都是静态页面(.html,.jpg等)，没有让用户输入的地方，那么可以利用，可以作为攻击点的地方也就不多。如果页面到处都是有输入，有查询，要求用户来参与的，你输入的越多，可能泄露的信息也越多，可能被别人利用的攻击点也就越多，所以和页面参数也是有关系的。AppScan声称测试用例的时候，也是根据每个参数来产生的，简单说，如果一个参数，对应了200个安全攻击测试用例，那么一个登陆界面至少就对应400个了，为什么？登陆界面至少有用户名和密码两个字段吧？ 每个字段200个攻击用例。
这个简单吧，还可以更复杂：如果遇到下面的两个地址，那要扫描多少次呢？
上面的两个地址有类似的，&？&号以前的URL地址完全一样，&?&号后面带的参数不同，这种可以认为是重复页面，那么对于重复页面，是否要重复测试呢？
这取决于&冗余路径设置&，默认的是最多测试5次；即，这种类型URL出现的前5次，那么就是要测试1000个攻击用例了。
如果再继续修改下：遇到下面的URL呢
&Item=open
每个URL里面都有2个参数，测试的次数就更多了。想象下，如果这个网页里面的参数如果是10个，或者更多的呢？比如很多网站提交注册信息的时候，要填写的内容足够多吧？
要进行的安全测试用例也就随之不断增加&
　　这是网站规模的影响，还有一个问题，就出在&每个参数，发送200个安全测试用例&这个假设上。这个假设的前提来源于哪里？ 来源于我们选择的扫描规则库。即你关心那些安全威胁，这个需要在测试策略里面选择。同样来参照杀毒软件，你会用杀毒软件来查找一些专用的病毒吗，比如CIH,比如木马；应用安全扫描也是一样的道理，如果有明确的安全指标或者安全规则范围，那么就选择之。这些可能来源于企业的规范，来源于政府的法律法规。就要根据你的理解，在这里选择。
　　很多时候，我们也很难在最开始的阶段，就把扫描规范制定下来，按照项目经理们的口头禅&渐进明细&，&滚动式规划&，在实践中，更多时候也是摸着石头过河，选择了一个扫描策略，然后根据结果分析，看是否需要调整，不断优化。比如选择默认的&缺省值&扫描策略，对网站进行扫描，发现其&敏感信息&里面会去检查页面上是否含有Email地址，是否含有信用卡号码等，如果我们觉得这些信息，显示在页面上是正常的业务需要，&我们就可以取消掉这些规则，所以扫描规则也很大程度上影响着我们的扫描效率。
=====================
& &注：本文复制网上一篇文章内容过多，不会发表到博客园首页，只在本博客显示。&