Web系统的漏洞检测扫描器性能分析
1 引言
互联网充满了信息和数据，是当今工作环境的核心 [1]。互联网及其超文本数据和信息被称为万维网，通常简称为 WWW 或 Web。用户通过 Web 应用 和浏览器与 Web 进行交互 [2]。Web 应用 是由服务器、服务器托管的网站以及后端数据库组成的系统。Web 应用程序 以方便高效的方式满足用户的多样化需求。因此，Web 应用程序 的数量不断增长。但随着 Web 应用程序 数量的增加，针对这些应用程序的攻击也日益增多。如图所示，思科年度安全报告 [3] 显示了 2012年–13 年安全警报数量的上升趋势。
为了应对日益增多的警报，我们使用自动漏洞扫描工具。这些扫描器采用黑盒方法，即它们不需要应用程序的代码。这些工具对 Web 应用程序进行扫描以发现潜在的 Web 漏洞。随后，这些漏洞将被修复，从而使应用程序更加安全。我们的工作重点是在不同条件下通过优先选择某一扫描器来提高这些漏洞的检测率。本文结构如下：第2节介绍相关研究工作。第3节说明提出的工作。第4节讨论所进行的实验及结果。第5节总结全文。
2 相关工作
许多研究工作都集中在漏洞这一主题上。
Sili 等人 [4] 在其研究中指出，目前大多数浏览器采用单体架构，模块之间没有明确的分离。所有模块在一个进程中运行，因此一个模块中的漏洞可能导致整个系统崩溃。为了解决这一问题，一些浏览器采用了模块化方法来提高安全性（如 Chrome），但它们也并非完全安全。Chrome 本身虽然涵盖了大部分安全问题，但仍存在一些漏洞，这些漏洞可能被利用来攻击其他网站，从而对其安全性提出质疑。
Johari 和 Sharma [5] 在研究中指出，在所有潜在的网络攻击中，主要的攻击类型是 SQL 注入（SQLi）和跨站脚本（XSS）。这些类型的攻击通过利用代码应用或脚本中存在的漏洞来实施。SQL 注入带来的风险更高，因为 它会影响对任何组织都至关重要的底层数据库。
Fonseca [6] 在他们的研究中指出，一半的 SQLi 攻击是通过数值字段利用实现的，即用于从用户获取数据的输入字段，如果输入未经过适当清理，则是最容易受到攻击的薄弱环节。
Duraes 和 Madeira [7] 提出了多种方法来检测和防止系统中存在的漏洞。根据他的研究，故障注入方法是检测和纠正漏洞最有效的方法。故障注入方法利用了大多数漏洞属于少量故障类别的特点。因此，我们可以利用这一知识编写更好的代码。
Avancini 和 Ceccato [8] 提出了一种通过关注对应代码响应的结构约束来检测输入参数漏洞的方法。他们使用污点分析尝试发现漏洞。当污染值被用于汇点语句时，即存在漏洞。他们通过使用遗传算法获得了更好的结果。该方法的主要缺点是大多数漏洞只能在运行时被检测到，因为输入值决定了代码的执行流程，在不同情况下，代码可能表现出不同的行为。
Wang [9] 提出了一种利用隐藏网页爬虫检测 Web 应用底层漏洞的方法。他们使用了信息通过隐藏网页爬虫收集信息，以有效构造攻击字符串，从而充分暴露系统中存在的漏洞。当与访问认证数据库表（AADT）结合使用时，搜索范围得以扩大。
德西亚特尼科夫 [10] 扩展了王欣方法论 [9]，并提出了一种预测代码中漏洞的方法。作者们根据响应页面在响应中归一化变化的距离，将响应页面分为三个聚类。由于每个响应总是对应一个请求，反之亦然，因此只需检查响应即可。基于这些聚类，作者能够以比其他扫描器更高的准确率预测系统中存在的漏洞。
Damjanovic 和 Djuric [11] 提出，通过结合特定 Web 应用的领域知识、函数式编程范式和模型驱动架构，可以构建攻击模型。利用这些知识可以以攻击树的形式对攻击进行建模，其全局目标是攻击系统。分析该攻击树可揭示系统中存在的漏洞。后续通过该攻击模型获得的进一步知识也可整合到系统中，以增强该方法的有效性。
布贾等人 [12] 采用四层方法来预防和检测 Web 系统中的漏洞。在他的模型中，他使用了 Boyer-Moore 字符串匹配算法，该算法减少了在暴力破解方法中匹配模式所需的时间。该算法主要用于病毒检测，能够在短时间内分析大量数据。它显著提高了检测速度。
许多研究人员正致力于提高扫描器的检测能力。由于目前许多最佳扫描器的检测能力仅在 40% 左右，这一上限并不理想。我们的目标是选择能够提高此上限的扫描器。这可以通过使用特定问题扫描器来实现，即根据现有的标准或问题选用不同的扫描器。
3 提出的工作
自从 Web 应用出现以来，用户现在能够进行许多操作，例如电子商务、网上银行等。为此，应用程序会向服务器存储和发送机密数据。然而，由于应用程序容易存在漏洞，这些漏洞可能被用于对 Web 应用发起攻击，进而导致机密数据泄露和系统操控。为了消除攻击概率，我们倾向于在初始阶段发现潜在漏洞，以防止系统在后期阶段变得脆弱。尽管付出了最大努力，但实现 100% 检测漏洞仍是不可能的。因此，一个较好的替代方案是先部署 Web 应用程序，然后对其扫描潜在漏洞，并在发现时及时修复，将其作为维护的一部分。然而，许多漏洞只有在现实世界中部署后才会暴露。此外，某些漏洞甚至不会导致成功攻击，因此投入不必要的资源并不是明智之举。
为此，我们使用漏洞检测扫描器来检测系统中存在的漏洞。它们采用黑盒方法来检测漏洞，即不需要应用程序的代码即可运行。
3.1 漏洞扫描器工作原理
Web 应用包含漏洞，这些漏洞可能被用于攻击应用，从而导致系统安全泄露。漏洞扫描器可用于检测这些漏洞。在成功检测后，我们可以从系统中修复这些漏洞，从而使系统更加安全。所有漏洞扫描器都采用以下基本流程来检测系统中存在的漏洞。
展示了扫描器的典型工作流程。每个阶段都利用其组件生成的信息来成功完成任务。不同的扫描器以不同的方式部署这些组件，从而极大地改变了扫描器的效率。
3.2 工具
在提出的工作中，我们试图为一些知名的开源扫描器建立基准。我们的工作重点是根据扫描耗时、检测到的漏洞数量等不同参数评估它们的性能。为此，我们选择了三个著名的开源漏洞扫描器。表1显示了用于此目的的扫描器列表。
这些扫描器在其领域中处于领先地位，是渗透测试用户下载量最多的扫描器。
| 序号 | 扫描器 | 创建年份 | 语言 | 接口 | 版本 |
|---|---|---|---|---|---|
| 1 | Wapiti | 2006 | Python | 命令行 | 2.3.0 |
| 2 | W3af | 2007 | Python | 命令行和图形用户界面 | 1.6.45 |
| 3 | ZAP | 2010 | Java | GUI | 2.4.0 |
3.3 数据集
对于本学位论文工作，我们使用了以下易受攻击的应用程序： 表 2 中列出的应用是用于检测在 OWASP 目录项目中列出的扫描器工作情况的一些标准应用 [13]。由于在真实环境攻击中，攻击 Web 应用属于违法行为并会受到惩罚。这些数据集由不同的商业扫描器开发人员托管，用于测试其扫描器或作为研究数据使用。Web 应用有多种可能的开发语言。然而，在本研究中我们仅选择用 PHP 编写的程序。通过限定为仅使用 PHP 编写的代码，可以更方便地展示相对性能差异。
在这项工作中，我们将这些易受攻击的 Web 应用程序作为输入数据提供给扫描器工具。通过分析输出结果，展示了漏洞扫描器的不同对比统计。
| 序号 | 项目名称 | Type | 网页链接 | 语言 |
|---|---|---|---|---|
| 1 | Acuart | 在线 | http://testphp.vulnweb.com/ | PHP |
| 2 | Vicnum 项目 | 在线 | http://vicnum.ciphertechs.com/ | PHP |
| 3 | 网络扫描器测试网站 | 在线 | http://www.webscantest.com/ | PHP |
| 4 | 零银行 | 在线 | http://zero.webappsecurity.com/ | PHP |
3.4 工作流程
我们提出了一种针对 Web 应用程序的漏洞检测方法。该提出的方法依赖于扫描器的报告生成及其自身的扫描器排名阶段。提出的工作的评估过程如
所示。在此工作中，首要任务是生成漏洞检测报告。
使用可用的不同扫描器。在此模型中，我们使用了三种可供用户使用的开源扫描器。将这些扫描器应用于在线可用的数据集，我们可以生成扫描器输出，即每个数据集的漏洞检测报告。之后，将提出的工作应用于这些生成的报告。
通过将提出的算法应用于生成的报告，基于指定的标准进行不同的分析。根据指定的标准对扫描器进行排名。对于不同的标准，不同的扫描器获得高排名。最终生成的报告展示了根据指定标准最有效的扫描器。
提出的算法：在提出的工作中，该算法分为两个不同的阶段运行。第一阶段是生成由漏洞检测扫描器产生的扫描报告。下一阶段利用这些报告对扫描器进行排名。该算法的伪代码如下：
初步的工作说明可以如下给出。
我们选取了 Wapiti 和 W3af 两款扫描器，对一些易受攻击的 Web 应用程序进行测试。在此情况下，我们选择在线易受攻击的应用程序，如 Vicnum 项目 [15]。分别使用指定的扫描器对该 Web 应用进行扫描，并生成漏洞检测报告。
成功生成报告后，进入算法的主要阶段，即根据不同的标准（如时间、针对特定漏洞的性能等）对这些报告进行分析。在此情况下，针对同一 Web 应用生成了两份报告。在比较各项标准时，我们以时间为标准。该算法将从时间效率方面展示这些扫描器的表现，即哪个扫描器完成扫描所需时间更短。算法将根据此标准对这些扫描器进行排名。标准的改变也会导致扫描器排名的变化。
4 实验与结果
本节介绍了所进行的实验及获得的结果，并对结果进行了详细说明。
4.1 系统需求
实验所用的系统配置如下所示。其中一些是运行所用扫描器的必要条件。本实验的硬件配置能够成功且高效地执行实验。
- 处理器 ：Intel Core i7 (3.4 GHz)
- 主内存 ：最低 1 GB
- 硬盘空间 ：最低 20 GB
- 输入设备 ：键盘和首选鼠标
本工作所需的软件要求如下：
-
操作系统
：Ubuntu 14.04
-
使用的工具和 IDE
：LaTeX, Gummi 编辑器。
4.2 实验结果
使用实验设置运行提出的算法时，我们根据指定的标准获得了不同的结果。
第一次运行：
在首次运行中，我们选择的标准是“检测到的漏洞总数”。在此运行中，我们希望找出能够生成最多漏洞检测警报的扫描器。
显示了在数据集上进行扫描时检测到的警报。警报是 Web 应用中的潜在漏洞。从图中可以明显看出，ZAP 检测到的警报数量多于其他两个扫描器。这主要是由于以下两个原因：
- 由于 ZAP 包含了 OWASP 标准化的十大漏洞配置文件，因此在检测漏洞时效率更高，因为它已具备这些漏洞的预知信息。
- 通常，一个请求有多个响应，因此 ZAP 会对同一请求产生多个警报。因此，警报检测数量较高。
可能看起来 ZAP 与其他两个工具不同，正在积累不必要的警报。但在许多情况下，漏洞通常是在满足特定条件时才会暴露出来，通过生成尽可能多的警报，ZAP 扩大了其覆盖范围。因此，考虑到这一点，ZAP 能够比其他两个工具发现更多的潜在漏洞点。
因此，根据我们的第一个标准，可以看出 ZAP 具有更高的性能，因而排名更高。
第二次运行：
本次运行中，我们选择的标准为“单次扫描最短耗时”。应用提出的算法后，得到的结果如 所示。
在这种情况下，ZAP 同样表现出最高效的性能，完成扫描所用时间在所有扫描器中最短。平均而言，ZAP 比 w3af 快 167%，比 Wapiti 快 236%。简而言之，ZAP 在完成扫描所需时间方面具有高效性能。由于启用不同的插件会显著影响扫描时间，因此该持续时间可能会有所不同。但该算法能够对每个数据集进行比较。
有趣的是，Wapiti 花费的时间比其他工具更长。其主要原因是，在未进行任何特定设置的情况下执行 Wapiti 时，它会逐一运行其所有模块，因此耗时更长，而 W3af 和 ZAP 仅运行基本模块配置。因此，所配置的插件和模块会显著影响持续时间。
第三次运行：
在此运行中，我们将标准设置为“漏洞严重性”，即高、中、低严重性的漏洞。提出的算法生成以下报告。
显示了 Acuart 数据集的报告 [14]。如我们所见，在本例中，ZAP 在每个部分生成的警报数量更多，表现突出。而 Wapiti 和 W3af 的表现相对相近。
显示了数据集 2（即 Vicnum 项目）的相同报告 [15]。其结果与 Acuart 数据集的情况基本相同。但有趣的是，尽管 ZAP 在其他类别中生成了大量的警报，但在各个扫描器统计中，高风险因素几乎相同。如果我们仅以高风险漏洞作为评判标准，那么所有扫描器的排名将会相同。
显示了数据集 3（即 Web 扫描器测试套件）的报告 [16]。针对零银行数据集也生成了类似的报告 [17]。如图 8 所示。
这两份报告具有相当有趣的关联因素。对于图 7，如果我们考虑中等风险漏洞警报，W3af 的为零，且高风险类型非常少，这可能是由于无法绕过认证页面，从而减少了检测到的漏洞数量。由于我们的算法使用扫描器报告作为输入，这也会影响算法的运行，导致对扫描器的排名不准确。因此，为了获得更好的排名，应期望拥有良好的扫描结果。至于图 8 的结果发生了变化，正如我们在其他结果中所看到的，ZAP 通常排名靠前，但在此结果中，ZAP 未能检测到高风险漏洞，而 W3af 却大量检测到了该类漏洞。因此，如果仅以高风险漏洞为标准，我们的算法会将 W3af 评为高效。这些结果表明，选择不同的标准会对同一报告给出不同的排名。
5 结论
这项工作涉及如何在不同情况下对 Web 漏洞扫描器进行优先级排序的问题。然而，这些扫描器在某些情况下表现良好，而在另一些情况下表现较差。因此，根据实际场景自适应地选择使用扫描器至关重要。提出的算法通过分析扫描器的输出来尝试解决这一问题，从而能够大致估计在何种标准下应使用哪个扫描器。本文展示了以“扫描时间”或“警报严重性”作为标准时会产生不同的统计结果。基于这些结果，提出的算法试图对漏洞检测扫描器进行排名。与所有研究工作一样，该算法仍远未达到完美。如果报告存在偏差或错误，可能会导致排名不明确。该算法尚不具备预测报告之间相似性的能力，若加入此功能，将有助于更准确地对扫描器进行排名。未来的工作包括添加此功能以改进结果，从而获得更好的效果。
扫一扫
535
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
