appscan安全扫描
(一)Appscan安装和破解
IBM AppScan是一款目前最好用的Web 应用安全测试工具,Rational AppScan 可自动化 Web 应用的安全漏洞评估工作,能扫描和检测所有常见的 Web 应用安全漏洞,例如 SQL 注入(SQL-injection)、跨站点脚本攻击(cross-site scripting)、缓冲区溢出(buffer overflow)及最新的 Flash/Flex 应用及 Web 2.0 应用曝露等方面安全漏洞的扫描。
一.下载Appscan安装包及补丁:
下载地址:
链接:https://pan.baidu.com/s/1pbxscV4VNkpEwGop6Gj6Kw
提取码:fana
版本是9.0.3.6
二.安装Appscan
1.运行安装包
2.选择安装语言为简体中文,点击确定按钮后,就开始安装了。
3.如果操作系统中没有.NET Framework 4.6.2 Web组件,这里提示需要安装即可。
4.点击【更改】按钮可以更改程序安装位置,默认是C盘。一般建议软件不要安装在C盘。然后点击【安装】到该目录。
5.如果需求扫描Web services点击【是】安装该插件,如果不需要点击【否】如果只是扫描web就不需要安装。
6.点击【完成】可完成软件的安装。
三.破解软件:
安装完成之后把LicenseProvider.dll文件将它复制放到安装目录下覆盖原来的文件。
四.运行软件:
注册完成,现在就可以使用AppScan 9.0.3.6的全部功能了,如下图所示:
注意:替换后运行软件还显示演示许可证,但是扫描目标已不受限制。
(二)Appscan的使用
1、web网站扫描的两种方式
【1】、没有验证码的网站
1.新建扫描:一般选择 常规扫描
2.选择扫描的平台:web或app
3.扫描配置向导
①配置URL和服务器
②配置登录管理
在扫描的过程中,可能会不小心碰到退出按钮导致Appscan注销.因此,要登陆到应用程序中,我们需要根据需求设置。
在测试的web没有验证码情况下,可以使用(1和3种登陆方法)
在web有验证码情况下,可以使用第二种登陆方法。推荐使用第一种方法。
记录:选择此项后,会出现一个新的浏览器,并尝试链接到指定的网站作为本扫描的起始URL.你需要输入账号和密码登陆到应用程序.这样设置之后你可以关闭浏览器,但是不要点击注销按钮。有时候你会发现打开的浏览器不是IE或者Mozilla,而是Appscan浏览器.你可以改变通过设置来改变这个。工具-->Options -->Advanced,设置OpenIEBrower的值0--Appscan浏览器,1--IE,2--Firefox,3--Chrome.如果该网站的行为在不同的浏览器下有所不同,这个设置将是非常有用的.
提示:每次注销之后,Appscan会提示你登陆到应用程序中.如果你打算整个扫描你的系统,你可以选择这个选项。
自动:在这里可以直接指定用户名和密码,当需要登陆到应用程序的时候。
在浏览器打开的界面(需扫描的web)上输入用户名和密码后,点击系统的登录按钮。如果登录成功,可点击【我已登录到站点】。appscan会开始分析登录操作,若成功记录下登录操作,会执行注销操作。
appscan执行完注销操作后,会回到配置向导界面:有标志,说明已记录成功。
③测试策略
扫描期间,AppScan® 发送的测试数量可以达到数千。有时,最好将扫描限制在仅扫描特定类型,以减少扫描时间。这是“测试策略”。几种测试策略说明:
缺省值:包含多有测试,但不包含侵入式和端口侦听器
仅应用程序:包含所有应用程序级别的测试,但不包含侵入式和端口侦听器
仅基础结构:包含所有基础结构级别的测试,但不包含侵入式和端口侦听器
侵入式:包含所有侵入式测试(可能影响服务器稳定性的测试)
完成:该策略包含所有 AppScan 测试,但端口侦听器测试除外。
关键的少数:包含一些成功可能性较高的测试精选,在时间有限时对站点评估可能有用
开发者精要:包含一些成功可能性极高的应用程序测试的精选,在时间有限时对站点评估可能有用
仅第三方:该策略包含所有第三方级别测试,但侵入式和端口侦听器测试除外。
生产站点:此策略“排除”可能损坏站点的侵入式测试,或测试可能导致“拒绝服务”的其他用户。
Web Services:该策略包含所有 SOAP 相关的非侵入式测试。
选择合适的策略后,点击【下一步】
④完成
选择--启动全面自动扫描,点击【完成】按钮。
4.启动扫描专家
扫描专家会先大致的探索被测网站,提出建议,以更好的扫描应用程序。
扫描专家建议:
可手动配置环境:提高性能和准确性。
5.开始测试
应用扫描专家的建议后,整个扫描就开始了。系统先会扫描大致的网站,了解所需测的页面、测试元素、发送请求数。扫描结束后,开始测试。
6.测试结束
7.生成测试报告
【2】、有验证码的网站,在【登录管理】设置登录方法为:提示
注意:点击【记录第一次登录】,在录制扫描的时候,会一直要手动输入登录用户名、密码、验证码
2、app扫描
【1】、打开appsacan,点击手动探索,选择【外部设备】-点击【记录代理设置】-点击【+】,加上手机的IP和电脑IP,点击【确定】。
【2】、手机端设置代理
【3】、在手机上操作某个app,尽量把所有的页面的增删改查的操作都做了
【4】、观察appscan外部流量记录器,可以看到操作app的时候发送的请求,选择外部流量记录器左边区域中需要检测的域,点击【确定】
【5】、最后Appscan会自动启动扫描,扫描完毕后,在appscan的菜单栏中的扫描选项中,选择【仅测试】,即可进行扫描:
3、REST Web service 接口扫描
近年来 Web 服务应用日趋广泛,人们往往利用 Web 服务集成不同平台的应用程序,或是将公共服务通过服务接口暴露给外部用户使用。这样便为黑客利用 Web 服务攻击企业应用提供了可乘之机。本文主要介绍如何利用 Rational AppScan 检测 Web 服务的安全漏洞。
目前使用的Web service主要为基于SOAP协议和基于REST架构,而基于REST架构越来越受到欢迎。众所周知,Rational AppScan的GSC为SOAP类型的web服务安全扫描提供了很好的解决方案,这里不再介绍。
对于REST类型的web服务,通过解读IBM的官方文档,可以知道主要有两种方法:
【1】、对调用服务的应用程序进行手工探索调用该服务,从而进行安全扫描;
【2】、利用代理使用“外部流量/客户机”进行安全扫描。
对于第1点只需要按正常的应用程序扫描对调用服务的应用进行扫描即可,但是需要确认调用服务的功能,以便进行手动探索。这里调用服务的应用既可以是页面的应用也可以是移动电话等设备的app。见图1,图2
图1 配置向导
图2 手动启动
手动探索调用服务的功能后,使用“仅测试”即可。
以下介绍利用POSTMAN或者SOUPUI进行探索,利用Appscan对探索进行扫描的方法。
如图1 ,打开配置向导,选择“外部设备/客户机”;
记录代理设置,如图3:
图3 记录代理
这里如果本机安装了POSTMAN或者SOUPUI,则选择“该设备上的外部客户机”,如果不是在本机上,则选择第一项“远程设备”,但是选择远程设备时要保证Appscan主机与安装POSTMAN或者SOUPUI的主机在同一网络;建议将Appscan与POSTMAN或者SOUPUI安装在同一机器上。
记录登录,直接点击【下一步】即可,见图4:
7、打开进行代理设置,新建POSTMAN新建工程,添加请求:
点击postman【File-Settings-Proxy】
点击New,创建collection-----> 添加请求-----》填写参数,发送请求,如下图所示:
图8 发送请求
9、Appscan流量记录器会显示监测到的请求信息,将全部请求探测后,点击【停止记录】,勾选左边的域,点击【确定】,而后Appscan会自动启动扫描,扫描完毕后,扫描选项点击【仅测试】,即可进行扫描:
10、如果使用的是SOUPUI,则在7、8步在SOUPUI中新建REST工程,进行代理设置,输入参数执行请求,如图10、11、12,后面操作与POSTMAN相同:
图10 SOUPUI新建REST工程
图11 代理设置
图12 发送请求
11、Appscan如果在配置向导时选择“Web Service”,将POSTMAN或SOUPUI的代理配置为Appscan配置选项中的代理,而后进行手动探索,也可取得同样的效果。
图13 Appscan代理设置
以上介绍了Appscan与POSTMAN或SOUPUI配合对REST服务进行安全扫描的方法,通过该方法可以有效的利用Appscan对Restful API进行安全扫描,保证接口服务的安全性。
计划阶段
在计划阶段,首先明确几个问题:
- 关心哪些类型的安全问题,根据这些安全问题来设置扫描规则。
- 要扫描的网站地址,网站的业务特点。
扫描策略的选择
试想,我们现在要扫描的是某个移动公司的网站系统,该网站系统提供多个内容频道,还可以连接到多个其他移动公司网站和业务网站,我们本次安全测试重点关心的是门户网站本身和其上面的网上营业厅业务。这就是一个比较明确的测试目标对象。
然后,确定扫描策略,我们主要关心该网站是否存在跨站点脚本执行和 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 个小时内完成。
文中取材来源网址:https://www.cnblogs.com/dydxw/p/10448910.html
https://www.cnblogs.com/dydxw/p/10449525.html
https://blog.csdn.net/trulyfeixue/article/details/86612854