Atropos：对Web应用程序服务器端漏洞的模糊测试技术

发布于2025年1月16日2025年7月19日作者:cve-20

Atropos：对Web应用程序服务器端漏洞的模糊测试技术

原创 FuzzWiki FuzzWiki 2025-01-16 03:35

基本信息

原文名称：
Atropos: Effective Fuzzing of Web Applications for Server-Side

Vulnerabilities

原文作者：Emre Güler; Sergej Schumilo; Moritz Schloegel; Nils Bars; Philipp Görz; Xinyi Xu; Cemal Kaygusuz; Thorsten Holz;

原文链接：https://www.usenix.org/conference/usenixsecurity24/presentation/g%C3%BCler

发表期刊：
USENIX Security 2024

开源代码：
https://github.com/CISPA-SysSec/atropos-legacy

一、引言

在本文中，作者提出了一种专门为PHP Web应用设计的，基于
快照和反馈驱动的模糊测试方法
ATROPOS。该方法考虑到了当前与Web应用相关的挑战，如维护会话状态、生成高度结构化的输入等。此外，本文还提出了一种反馈机制，用于
自动推断Web应用使用的键值结构
，使其能够绕过应用的浅层解析阶段，有效探索更深层的程序。

与性能最好的静态分析方法相比，ATROPOS多发现了32%的错误，在不同测试套件上的报误率都为0。在覆盖率方面，该方法比WEBFUZZ和WFUZZ分别平均多覆盖了50%和230%的代码。在分析真实的Web应用时，
发现了7个以前未知的漏洞
。

二、研究动机

库模糊测试需要一个模糊测试驱动（Fuzz Driver）来将库提供的API转化成一个可执行程序，从而对库进行模糊测试（如图1）。为了节省编写驱动的人力成本，并提升库模糊测试的覆盖率，学术界进行了许多自动化生成fuzz driver的尝试。

与手动编写的模糊测试驱动程序相比，自动化生成技术通过从源代码或运行时反馈中学习库API的使用来导出模糊测试驱动程序。FUDGE、FuzzGen和UTopia静态提取源代码中的API使用代码，而APICraft和WINNIE则从进程的执行轨迹中动态记录API调用序列。然而，
由于轨迹仅包含消费者代码调用的API调用序列
，这种方法无法学习消费者代码中不存在的有效API使用
。最新的模糊测试驱动生成解决方案Hopper将库模糊测试问题转化为解释性模糊测试问题，从API调用的动态反馈中学习有效的API使用。尽管它可以覆盖大多数API函数，但在广阔的搜索空间中找到到达深层状态的有用API调用序列需要进行许多尝试。

近年来兴起的大语言模型（LLM）技术在代码生成领域表现卓越。借助大语言模型，论文可以很轻易地生成对于特定库而言合法的API调用序列，而不需要进行长时间的探索。之前基于LLM的库模糊测
试工具，其提
示词所涵盖的内容和场景相对有限，于是本文希望
扩充提示词的空间，通过变异提示词的方式来实现对于库深层状态的探索
。

传统的模糊测试方法已被证明在编译成本地二进制文件的语言中非常有效，但是它们无法直接应用于使用解释型语言（如PHP）编写的服务器端Web应用程序。其主要面对的挑战有如下三点：

（1）
服务器端Web应用程序的复杂接口
：传统的模糊测试通常通过标准输入或文件传递数据，而Web应用需要模拟Web服务器和浏览器的环境。并且，Web应用程序的输入通常包含开发人员设置的具有语义意义的标识符（如表单字段名、Cookie、URL参数等），随机生成的输入很难匹配这些标识符，导致测试失败。

（2）
状态化的环境
：Web应用程序会为用户会话维持大量状态，这些状态分散在许多组件中，并且状态的持久性会影响后续的所有操作，难以在维持大量状态的前提下进行高效的模糊测试。状态的分散性和持久性会影响模糊测试器的执行，尤其是在数据删除或注销等关键操作影响后续输入的情况下。

（3）
漏洞检测机制
：解释型语言（如PHP或Javascript）中的应用程序错误通常不表现为违反内存安全，无法使用依赖内存崩溃信号的标准错误机制进行检测。

而针对上述的问题，作者设计了ATROPOS：

(1)
提出了ATROPOS
，一种新颖的
基于快照和反馈驱动
的Web应用模糊测试方法，可检测出8种类型的服务器端漏洞

(2)
引入了一种新的反馈机制
，可以在运行时直接从解释器中提取相关信息，并为随机突变器提供信息。

(3)
介绍了8种新的错误检测机制
，能够有效地检测出不同类型的服务器端漏洞，不需要重量级的程序分析技术或复杂工具，具有检测率高、报误率低的特点。

三、概述

图 1 ATROPOS架构的概述图

ATROPOS的架构如图1所示。一般来说，模糊测试的对象是一个由多个进程组成的Web应用程序，例如，PHP解释器执行应用程序并与数据库、文件系统和其他潜在组件交互。由于组件都高度依赖于其状态和环境，因此需要在隔离的系统（例如，虚拟机）中运行，以便能够创建快照并重置状态。为了引导模糊测试过程，本文对PHP解释器进行插桩，以提供覆盖率反馈。ATROPOS内部的工作方式类似于AFL++等模糊测试器，使用了与AFL++相同的种子选择和优化算法，包含了经典的字节级变异操作。为了针对Web应用程序进行模糊测试，本文作者提出了一些改进，以应对Web环境中的独特挑战：

（1）
文件选择
：由于Web应用程序通常是由多个PHP文件组成的，且这些文件在测试前对测试器是已知的，因此ATROPOS在每次迭代中随机选择一个文件进行测试。

（2）
多请求输入
：每个测试输入可以包含多个请求，使模糊测试器能够在一次迭代中顺序运行两个或更多的PHP文件。

（3）
结构化输入变异
：由于Web应用程序的请求高度结构化，ATROPOS提供了一个自定义的变异器，反映输入的键值结构。

1．高级反馈机制

（Advanced Feedback Mechanisms）

一个Web应用程序通常由解释器执行，该解释器从Web服务器接收输入，而服务器则从Web浏览器接收输入。为了降低开销并提高测试性能，本文使用FastCGI接口替代Web浏览器和服务器，以实现更直接的通信。

因为PHP Web应用程序大量使用以键值对形式存在的语义令牌，所以需要高度结构化的输入。不同于传统模糊测试对输入进行随机变异，本文作者设计基于对Web应用程序输入的结构化表示，采用多种技术生成有意义的键值对。例如，识别Web应用程序期望的输入结构部分，并以字典的形式提供给模糊测试工具，使其能够精确地变异特定的键和值。

以下技术构成了本文针对PHP Web应用程序的高级反馈机制，这些机制与测试器的覆盖率反馈相辅相成。

推断应用程序特定的键
：当Web应用程序接收到请求时，会根据来自Web浏览器的请求填充多个全局映射（例如 $_GET、$_POST 或 $_SERVER），这些映射可供Web应用程序访问。因此模糊测试器也必须填充被Web应用程序访问的键。这些键通常是复杂的语义令牌，难以随机生成。ATROPOS通过挂钩PHP解释器访问这些全局映射的过程，实现对执行环境的完全控制。当检测到新的访问时，该挂钩会将被访问的键作为反馈提供给测试器，从而允许在下一次模糊迭代中设置预期的键。

例如图1中的输入➊：在处理最初的随机输入abc=xyz时，Web应用程序访问了键page，挂钩将其报告为缺失的键。ATROPOS能够在后续的请求➋中设置该键。这个方法适用于动态生成和静态定义的键。

推断预期值
：为了测试应用程序更深层的逻辑，模糊测试工具不仅需要正确的键，还需要特定的值，例如 page=login。传统的实现方法如污点分析、符号执行等存在状态爆炸和开销过大的问题。本文使用类似于输入与状态对应的启发式方法，针对Web应用程序进行了调整。在多数情况下，输入会直接与特定值进行比较，且Web应用程序的输入基于字符串，所以ATROPOS挂钩了PHP解释器中所有字符串比较函数，例如zend_string_equal_val。当ATROPOS遇到字符串比较时，挂钩会将相关信息作为反馈传递给测试器。在下次测试迭代中，可以随机将“错误”的值替换为预期值。

在图1中，Web应用程序的第3行的if语句将随机输入xyz与预期值login进行比较。收到正确值作为反馈后，测试器可以将xyz替换为login，并在第三次测试迭代➌中发送有效输入page=login，从而解锁应用程序更深层的逻辑。

该过程不仅适用于完整字符串的比较，还适用于部分字符串比较。但是对于一些极端的输入变换，如Hash加密和Base64编码时，仍具有挑战性。在本文中，作者强调困难不在于生成和维护HTTP输入格式，而在于推导出正确的键值对。

推断正则表达式
：为在实际应用中，Web应用程序还会检查输入是否匹配正则表达式，例如验证输入是否为有效的电子邮件地址或电话号码，如图2所示，在这种情况下，ATROPOS使用上述机制，将观察到的正则表达式作为反馈传递给测试器。然后，测试器可以利用XEGER等工具生成一个符合该正则表达式的随机字符串。

任务部分要求LLM为指定的库生成包含特定API集合的模糊测试驱动。

上下文部分包括了包含上述API的头文件、API的签名、API所使用的类型定义。
上下文部分是对于所选API集合的补充说明。

可以说，PromptFuzz的提示词由所选的API集合唯一确定。这样一来，本文所设定的变异提示词的目标就转化为了API集合的变异问题。

图 2 在执行时观察正则表达式，将其反馈给测试器

推断HTML中的键
： ATROPOS会解析应用程序生成的HTML输出，提取可能有用的键或键值对。例如图3中所示，在登陆表单中将提取出键user和passwd。该方法是一种简单的爬虫形式，不会进一步请求页面。该方法是可选的，仅作为一种优化技术。通过上面提出的推
断机制可以在多次模糊测试迭代中发现所有被使用的键和值，但前提是Web应用程序至少访问过一次该键或值以触发反馈。通过这种爬取，测试器可以一次性发现嵌入在HTML输出中的所有静态键，但无法发现动态生成的键。

图 3 HTML登录页面的例子

由于收集并将反馈信息返回给测试器的过程成本较高，ATROPOS仅在每次新的输入产生新的覆盖时，执行一次动态高级反馈机制。因此，这种开销对于每个种子文件来说是一次性的，与整个模糊测试过程相比，额外开销可以忽略不计。

2．状态化的环境

（Stateful Environment）

为了在不影响模糊测试效率的情况下满足 Web 应用程序维护复杂状态（例如会话、数据库、文件系统等）的需求，本文将 Web 应用程序运行在一个适合快照和恢复的隔离环境中。该方法与其他Web应用模糊测试工具（如WEBFUZZ）不同的是，后者需要通过人工领域的专家手动控制目标应用程序来实现，控制过程容易出错并且缺乏隔离性。若执行的代码更改文件系统、数据库等，会对后续执行产生重大影响，即使两次运行的输入相同，也可能导致触发的漏洞无法复现。

模糊测试工具将Web应用程序运行在隔离环境中，使用针对模糊测试优化的快速快照，不仅可以在处理每个输入后便捷地恢复整个系统状态，还能保证发现的漏洞是可以复现的。为了实现该功能，本文作者将ATROPOS构建在NYX之上。ATROPOS在初始化所有资源（例如数据库）后创建一个快照，并在每次模糊测试迭代后恢复到该快照，即在 Web 应用程序处理完模糊测试输入或在一秒超时后恢复。由于在恢复后无需重新启动数据库或任何后台运行的应用程序，ATROPOS 避免了启动时的长时间初始化阶段。

对于一些需要多个输入链式执行，且在多次执行之间不重置状态的漏洞，本文采取每N个输入后重置一次的策略。漏洞越复杂，所需的状态累积越多，模糊测试工具生成触发漏洞的输入的可能性就越低。

3．漏洞检测机制

（Bug Oracle）

许多类型的Web应用程序软件故障不会表现为内存安全违规，因此不会导致崩溃，无法被识别为漏洞。基于这一观察，作者提出了一组定制的漏洞检测机制来识别此类漏洞。

原理
：本文的方法依赖于两个通用条件来识别漏洞：潜在的不安全函数表现出异常或可疑行为，通常会产生警告或错误；该不安全行为是由攻击者控制的输入触发的。满足这两个条件，漏洞检测机制就会报告找到的特定PHP漏洞。

作者认为大多数常见漏洞都是由一些关键函数引起，例如mysqli_query() 或 unserialize()。通过对这些函数进行代码插桩，可以将它们转化为对特定漏洞类别敏感的漏洞检测机制。与静态分析不同的是，本文所提方法只对关键函数插桩，不会对整个PHP程序进行建模，并使用不同的输入执行Web应用程序。

如图4中的a所示，测试器可能会生成一个输入并将其传递给mysqli_query()，从而生成一个无效的SQL查询。由于测试器生成的随机输入未经清理，该查询很有可能引发PHP语法错误或警告，这就满足了第一个条件可疑的函数行为，但并不意味着攻击者控制了查询。通过提出的反馈机制，ATROPOS可以在输入中插入一个特殊的字符串，并观察该字符串是否出现在查询中。若出现，则推断攻击者控制了查询。满足上述两个条件时，会报告漏洞。

创新性
：首次把使用错误作为代码审查反馈的技术与自动化推理相结合，以检查攻击者控制的输入是否到达特定的函数。这一过程得以高效实现，主要通过避免成本较高的技术（如污点分析），并采用了一种针对 Web 应用程序的输入与状态对应方法。本文为8种漏洞类型提供了检测机制，并将检测机制定位于PHP解释器中，即使在被测试的web应用程序禁用错误或警告输出时，也能够感知到漏洞。

漏洞触发
：为了加快找到触发错误的输入的过程，ATROPOS 包含了一个潜在漏洞触发字符串列表，例如包含不同引号的字符串，这些字符串常常需要用来突破SQL查询中的字符串。该方法类似于AFL 等模糊测试工具将“魔术值”插入输入中的方式。

新的漏洞检测机制
：作者为SQL 注入、远程代码执行、远程命令执行、本地和远程文件包含、PHP 对象注入、服务器端请求伪造（SSRF）、任意文件读取与写入、文件上传这8中种服务器端Web应用程序提出了定制的漏洞检测机制。

1）
SQL 注入
：如果未经清理的输入导致SQL查询在处理时出现语法错误，并且该查询包含由模糊测试工具控制的输入，则此漏洞检测机制会报告一个漏洞。

2）
远程代码执行
：如果模糊测试工具控制的输入在编译动态 PHP 代码时引发语法错误（例如，在调用eval()时），该漏洞检测机制会报告一个漏洞。若输入由测试器随机生成，其无效的概率很高。图4中的b提供了一个关于eval()函数的简短示例。此外，ATROPOS 注入有效的PHP代码并执行时会报告一个漏洞，因为攻击者不应能够在 web 应用程序的上下文中执行自定义代码。

3）
远程命令执行
：这个漏洞检测机制会监视尝试执行不存在的二进制文件的情况。此外，ATROPOS尝试注入一个命令，试图执行放置在虚拟机中的自定义二进制文件，从而自动触发该漏洞检测机制。如图4中c所示。

4）
本地和远程文件包含
：如果调用与文件相关的函数（如 include() 或 require()）时出现错误，表明文件不存在，而文件路径中包含模糊测试工具控制的输入，则会报告文件包含漏洞，如图4中的d所示。

5）
PHP对象注入
：如果攻击者控制的输入最终进入反序列化调用unserialize()，则报告一个对象注入漏洞。由于序列化数据是结构化的输入，解析错误可以用来检测可疑行为，类似于 SQL 注入漏洞检测机制。如图4中的e所示。

6）
服务器端请求伪造
：如果资源请求可以指向私有地址范围（例如，http://192.168.0.1），并且还包含模糊测试工具控制的输入，则该漏洞检测机制会报告 SSRF 漏洞，如图4中的f所示，通过控制file_get_contents()的主机。

7）
任意文件读取与写入
：由于很难判断哪些文件操作是恶意的，作者保守地将这个漏洞检测机制限制为PHP文件。若web应用程序尝试读取、写入、删除或重命名包含模糊测试工具控制的输入的 PHP 文件名时，则会触发此漏洞检测机制。此外，ATROPOS 会尝试提供一个标记PHP文件，该文件会触发漏洞检测机制，并根据对其应用的文件操作报告漏洞。如图4中的g所示。

8）
文件上传
：由于该类漏洞的识别也高度依赖上下文语境，作者保守地认为仅上传PHP文件才是安全问题，如果通过相应的挂钩函数（move_uploaded_file()）上传PHP文件成功，则认为这个漏洞已被触发，如图4中的h所示。

图4 八种漏洞类型的代码示例

ATROPOS通过在PHP解释器中对特定的函数安装钩子来实现上述的漏洞检测机制，具体的函数如表1所示。

表1 每个漏洞检测机制所挂钩的函数

四、具体实现与实验

1．具体实现

使用C、Python和Nim构建了一个名为ATROPOS的原型。ATROPOS分为两个组件：（1）前端，负责生成输入并决定接下来要模糊测试的种子，(2)后端，负责在虚拟机中运行Web应用程序。这两个组件通过共享内存和超调hypercalls交换信息。

ATROPOS的实现围绕着主要的模糊测试执行循环，循环需要：(1) 生成和变异输入，(2) 接收反馈，了解Web应用程序执行了哪些代码区域，(3) 报告发现的漏洞，(4) 恢复环境到其初始状态。

生成输入
：通过ATROPOS前端自定义的变异器随机生成输入，并利用所提出的高级反馈机制优化输入。将输入转为FastCGI参数，并传递给虚拟机中的代理程序。ATROPOS支持的外部输入源主要是$_GET、$_POST、$_COOKIE、$_SERVER。

执行输入
：基于NYX框架构建ATROPOS，使用Ubuntu 22.04作为虚拟机的操作系统。系统内存有一个agent应用程序来创建和恢复快照、处理前端的输入。输入通过FastCGI从前端传递给虚拟机中的agent，agent模拟服务器的角色将输入转发给Web服务器，后台运行SQL服务器确保SQL查询成功，完成输入执行后，agent请求使用快照机制恢复系统到初始状态。

代码覆盖率获取
：通过pcov插件对PHP 7.4进行插桩以获取覆盖率反馈。

运行时反馈：PHP 解释器和 pcov插件提供关于失败比较、缺失键和正则表达式执行的信息。这些反馈通过NYX超调传输到前端，被变异器读取。

2．实验设置

本文在三个实验中评估了ATROPOS原型的实现。首先，检查ATROPOS是否能在各种基准测试中检测到比现有工具更多的漏洞，并比较其与现有工具在假阳性方面的表现。其次，分析ATROPOS与现有工具的代码覆盖率。最后，研究ATROPOS是否能够在真实的PHP Web应用程序中发现新的漏洞。

本文使用了5台配置为ntel Xeon Gold 6230 @ 2.10GHz处理器（40个物理核心）、192GB内存，并搭载SSD存储的机器。为了更好地评估ATROPOS的能力，本文考虑两种场景：

1）单核模式：ATROPOS在单个核心上运行，作为基准。

2）多核模式：ATROPOS在40个物理CPU核心上运行，更接近实际应用场景。

这两种区分能够衡量ATROPOS在资源增加时的拓展能力。在单核模式下，设置运行10次，每次持续24小时。在多核模式下，单次运行960 CPU小时，完成3次运行。每次运行时种子集为空。具体的配置可见github界面。

测试套件
：本文选择了3个涵盖多种漏洞类型的测试套件作为漏洞基准：
Damn Vulnerable Web Application (DVWA)、Xtreme Vulnerable Web Application (XVWA)、buggy web application (bWAPP)
。这3个测试套件共包含177,000行代码和52个与评估相关的服务端漏洞，涵盖了ATROPOS支持的8种漏洞类型，可以用来计算真阳性率和假阳性率。

指标
：使用检测到漏洞的中位数并向下取整，计算真阳性率（报告的实际漏洞在所有漏洞中的比例）和精确率（报告的漏洞中实际漏洞的比例）。

3．实验评估

实验1：查找漏洞的有效性

在该实验中，作者评估了在3个测试套件中识别漏洞的能力，并统计了报误的数量。选取了4个静态分析工具：SONARQUBE、PROGPILOT、PSALM、PHPCS-SECURITY-AUDIT；选取了2个网络漏洞扫描器：ZED ATTACK PROXY (ZAP)、WAPITI；选取了3个针对Web应用的模糊测试工具：WITCHER、WFUZZ、CEFUZZ。

作者为所有工具提供有效的会话（或登录凭证）和所有可访问 PHP 文件的列表。在最佳情况下，自动错误查找工具会发现所有错误，同时不会报告误报，即应该同时具有较高的真阳性率和较高的精确度。实验结果如表2所示，与静态分析工具相比，ATROPOS发现了更多的错误。只有ATROPOS、SONARQUBE 和 WITCHER 没有任何误报，但与此同时，ATROPOS 发现的错误比其他两个工具发现的错误总和要多。WFUZZ 没有发现任何错误，因为它的爬虫和错误查找能力受到严重限制，除非使用正确的键值配对设置 GET、POST 和 Cookie 手动指向特定的目标 URL。CEFUZZ在DVWA和bWAPP测试套件中都发现了8个远程命令/代码执行漏洞，ATROPOS也达到了相同的结果，并且还能检测到额外类别的漏洞。

表2 静态分析工具、fuzzer和IR-Fuzz的准确率比较

二阶漏洞
：DVWA中有一个二阶漏洞，这要求攻击者首先执行一个PHP文件并在会话中存储一个值，然后执行另一个PHP文件，在这个文件中，这个值在SQL查询中被使用时没有经过清理。ATROPOS成功触发了这个漏洞。在静态分析和网络扫描工具中，只有PHPCS-SECURITY-AUDIT检测到了这个漏洞，但它还报告了额外的27个此类漏洞的误报。作者认为，ATROPOS 不需要执行污点分析来追踪跨多个执行步骤的输入，这使得这一漏洞类型对于静态分析工具来说很难检测到。

漏报漏洞
：在40核心的运行中，ATROPOS 仅遗漏了3个漏洞：两个是与文件上传相关的漏洞，一个是 XVWA 中的远程命令执行漏洞。上传漏洞的遗漏可能是由于缺乏足够好的种子来生成特定的HTTP请求头部和键值对，而远程命令执行漏洞可能与文件覆盖不完全有关。此外，一个上传漏洞需要通过一个罕见的 getimagesize() 检查，ATROPOS 通过了该检查并成功触发漏洞。这表明种子库的质量对漏洞发现至关重要。

实验2：代码覆盖率评估

作者使用覆盖率引导的模糊测试器WEBFUZZ和黑盒Web应用模糊测试器WFUZZ作为基线进行评估，并且计算了ZAP 和 WAPITI 的代码覆盖率。测试目标除了上面的三个测试套件外，还包含了10个真实的Web应用程序，其中有3个单页应用程序。为了使不同工具的代码覆盖率结果具有可比性，所有的工具都使用WEBFUZZ的插桩机制。对于除ATROPOS 以外的所有工具，手动删除负责注销或重置数据库的文件，以避免在维护状态时出现问题。对于 ZAP 和 WAPITI，使用相应的用户登录凭据进行配置。

让所有工具在单核心上运行十次，每次24小时，并使用Mann-Whitney U测试进行统计显著性分析。通过计算每个 Web 应用程序相对改进的几何平均值来得出平均改进。

结果如图5所示，ATROPOS 在13个Web应用程序中的12个上实现了最高的代码覆盖率。平均而言，ATROPOS比ZAP多覆盖了63%的基本块，比WAPITI多46%，比WFUZZ多80%，比WEBFUZZ多50%。根据 Mann-Whitney U测试，除DOWN52之外的所有案例中，这些覆盖率差异在显著
性水平p < 0.05 下均具有统计显著性。在DOWN52的测试中
，几乎所有工具的运行都达到了代码覆盖的饱和状态。该实验表明，仅尝试所有可能的输入（如WFUZZ）存在严重限制，而简单的Web爬虫机制（如 ZAP、WAPITI 和 WEBFUZZ）则更为有用。然而，更关键的因素是解决 Web 应用程序中特有条件的能力（例如字符串比较）以及发现 HTML 输出中未直接嵌入的键和值的能力。ATROPOS的设计使其能够完成这两项任务，从而显著提高了代码覆盖率。

图 524小时内每个目标相对于表现最佳的工具的基本块覆盖率

执行吞吐量：本实验还测量了WEBFUZZ和ATROPOS在bWAPP上的执行次数。ATROPOS 在bWAPP上的执行效率远超WEBFUZZ，在相同时间内，ATROPOS 执行的输入数量是 WEBFUZZ 的2.3倍。尽管 WEBFUZZ 配置了8个并发工作线程，但它没有尝试恢复运行环境，导致性能下降。实验表明，避免HTTP请求，绕过Web服务器显著提升了ATROPOS的性能。

实验3：发现现实世界中的漏洞

该实验用于检测ATROPOS在现实世界中检测软件漏洞的能力。作者选取了56个运行在PHP 7.4上的Web应用程序进行模糊测试，共发现了7个漏洞。为了验证静态分析和网络漏洞扫描器是否能找到相同的漏洞，以及ATROPOS是否具有优势，作者对所有目标运行了这些工具，并检查它们是否能找到 ATROPOS 报告的漏洞。实验结果表明ATROPOS是唯一能发现所有漏洞的工具，静态分析工具平均只能发现大约40%的漏洞。ZAP、WAPITI和WFUZZ没有发现任何漏洞。具体情况如表3所示。

表3 ATROPOS和其他工具在发现现实漏洞中的表现

实验4：消融实验

为了研究ATROPOS各个组件的有效性，作者设计了一个基础版本的，禁用所有的高级反馈机制，然后逐步添加一个个功能。通过这种方式，衡量键提取、值提取、爬虫优化以及正则表达式推断的影响。

使用bWAPP作为测试对象，对所有的变体进行三次24小时的实验，并比较发现的漏洞数量和代码覆盖率的中位数。具体结果如表4中所示，随着反馈机制的增加，发现的漏洞数量也会增加。禁用键值推断机制显著减少了覆盖率，因为随机生成的字符串不太可能深入应用程序更深的层次，无法触发漏洞。添加了正则表达式推断机制后相对差异不大，可能是因为该效果根据Web应用程序的不同而有所变化。

表4 在bWAPP上进行消融实验的结果