跳到主要内容

4.4 Fuzztag - 智能化请求构造引擎

在前序章节中，我们已经基本掌握了 Web Fuzzer 的批量发包能力（4.2）与各项执行配置（4.3）。然而，真正驱动“批量”这一核心能力、将静态请求模板转化为成千上万个动态测试用例的，是 Yakit 的核心技术之一：Fuzztag。本章将从原理层面剖析 Fuzztag 的工作机制，并由浅入深地展示其在各类安全测试场景下的基础及高级用法，帮助用户掌握这一无需编程即可实现复杂自动化测试的强大工具。

4.4.1 Fuzztag 核心原理：从静态文本到动态生成器​

Fuzztag 是 Yakit 专为安全测试设计的声明式模板语言（Template-based-DSL），其核心理念是将测试逻辑以标签形式嵌入原始请求数据中，实现了数据与逻辑的无缝融合。与传统安全测试工具需要在用户界面上分离标记位与配置 Payload 的方式不同，Fuzztag 通过将数据生成与处理逻辑直接集成到请求文本中，极大提升了测试用例构造的灵活性、表现力以及可编程性。其工作原理可以概括为一个“解析-生成-渲染”的过程，依托强大的 Fuzzer 后端引擎，通过结构化的解析与动态生成机制，将静态文本转化为批量化的动态测试请求。本节将深入剖析 Fuzztag 的核心原理，详细讲解其实现机制，并通过图示揭示 Fuzztag 的内部工作方式。

词法与语法分析：构建抽象语法树（AST）​

Fuzzer 引擎首先对输入的原始请求文本进行解析，生成一棵抽象语法树（AST）。这一过程分为两个层次：

  • 词法分析：将请求文本分解为最小单元（Token），例如静态文本、Fuzztag 标签的起始标记 {{、结束标记 }}、函数名、参数等。

  • 语法分析：基于词法分析结果，构建 AST，其中节点分为两种类型：

    • 静态内容节点（Data Node）：普通文本部分，例如请求中的 id= 或 &name=admin，直接存储原始文本内容。

    • 动态标签节点（Tag Node）：符合 {{...}} 语法的部分，例如 {{int(1-100)}}，包含函数逻辑和执行状态。 每个动态标签节点会被进一步解析为函数名（如 int）、参数（如 1-100）以及可能的标签属性（如 ::sync 或 ::dyn），为后续的生成逻辑提供结构化数据。

为了更清晰地理解，下图精确展示了这一过程：

图：HTTP请求词法语法分析与AST构建示意图

节点求值与生成：动态生成器的构建与执行​

解析完成后，Fuzzer 引擎遍历 AST，构建生成器：

  • 静态节点生成器：直接返回存储的文本内容，无需额外计算。

  • 标签节点生成器：每个动态标签被视为一个独立的生成器（Generator），其内部可以有多个子生成器节点作为执行参数。当标签节点生成器执行时会调用它的所有子生成器节点，再执行当前节点。

如图是输入文本id={{int(1-{{int({{int(1-3)}}-{{int(4-6)}})}})}}生成的AST案例：

图：AST解析结构图展示动态生成器节点分解

数据传播与组合：自底向上的生成​

不同于传统的笛卡尔积组合方式，Fuzztag 采用自底向上的数据传播机制，确保生成结果的全面性并等效于笛卡尔积效果，同时支持更灵活的控制（如同步渲染）。这一过程通过以下步骤实现：

  • 传播过程： 执行从叶节点开始，数据自下而上逐级传播至根节点。每个叶节点（静态节点或动态标签节点）生成数据后，将结果传递给其父节点。父节点根据子节点的数据进行组合，生成新的数据集合后继续向上传播，直至根节点形成完整的测试用例。 示例：以上面小节中的复杂案例：id={{int(1-{{int({{int(1-3)}}-{{int(4-6)}})}})}} 为例，节点执行顺序为：

    • 节点 5（{{int(1-3)}}）：生成数据 [1, 2, 3]，向上传播。

    • 节点 7（{{int(4-6)}}）：生成数据 [4, 5, 6]，向上传播。

    • 节点 4（{{int(1-{{int(4-6)}})}}）：接收节点 5 的 [1, 2, 3] 和节点 7 的 [4, 5, 6]，组合生成参数集，如 ["1-4", "2-4", "3-4", "1-5", "2-5", "3-5", "1-6", "2-6", "3-6"]，继续传播。

    • 最终向上传播至根节点（AST Root）：整合所有节点数据，生成完整请求。

  • 同步传播： 对于标记了 ::sync 的标签（详见 4.4.2.3），多个同步标签的生成器在同一轮次内同时执行。执行完成后，其结果一次性向上传播至父节点，确保数据的一致性。

4.4.2 Fuzztag 从入门到核心用法​

掌握了 Fuzztag 的核心原理后，本节将聚焦于其实际操作。我们将遵循一个渐进式的学习路径，从最直观的图形化辅助工具开始，逐步过渡到高效的快捷操作与高级的手动编写方式。同时，我们将对 Fuzztag 的功能进行分类，帮助您理解不同标签的设计理念和适用场景。

4.4.2.1 Fuzztag 的三种核心输入方式​

Yakit 提供了三种层次分明的 Fuzztag 输入方式，以满足不同熟练程度用户的需求，确保无论是初次接触还是资深专家，都能找到最高效的工作流。

基础功能：使用全局 Fuzztag 助手进行探索与学习​

对于初学者或需要探索不熟悉标签的用户，最推荐的方式是使用全局“Fuzztag 助手”。它是一个集成了完整标签库、实时调试器和详细文档的强大工具。

  • 访问方式：在左侧的“请求包配置”面板中，点击“Fuzztag 辅助”按钮。

  • 核心功能：该助手会弹出一个独立的窗口，其中包含了 Yakit 支持的所有 Fuzztag。用户可以按分类浏览，或通过搜索快速定位。选中任意标签，右侧会立即显示其功能描述、参数说明及使用示例。用户还可以在此窗口内直接调试，预览生成结果，确认无误后一键插入到请求包的光标位置。

  • 适用场景：当您不确定使用哪个标签、忘记标签语法或需要验证复杂嵌套标签的输出时，全局助手是您最可靠的参考手册和沙盒环境。

图：Yakit Fuzzer Tag调试工具界面及Zlib编码参数详情

快捷方式：通过上下文菜单快速处理数据​

当您对常用标签有一定了解，并希望提升操作效率时，上下文“智能菜单”是您的不二之选。这种方式尤其适合对已有数据进行编码、加密等处理。

  • 访问方式：在请求包编辑器中，用鼠标选中您希望处理的一段数据（例如，一个参数值）。此时，系统会自动弹出一个上下文相关的菜单。

  • 核心功能：该菜单会智能推荐最常用的处理型标签，如 Md5 编码、Base64 编码、URL 编码等。您只需单击所需选项，Yakit 就会自动用对应的 Fuzztag 将您选中的内容包裹起来，例如将 value 变为 {{md5(value)}}。

  • 适用场景：这是日常渗透测试中最高频的操作之一，适用于需要对特定参数进行快速编码或转换的场景，极大地简化了重复性工作。

图：Yakit 右键菜单展示多种编码工具选项

快捷补全：利用代码自动补全高效编写​

对于已经熟练掌握 Fuzztag 语法的高级用户和 Yaklang 开发者而言，直接在请求包中编写是最快的方式。Yakit 为此提供了强大的代码自动补全支持。

  • 访问方式：在请求包编辑器中，手动输入 {{。

  • 核心功能：当您输入 Fuzztag 的起始标记 {{ 后，编辑器会立即触发一个自动补全列表，列出所有可用的标签及其简要说明。您可以通过键盘上下选择，或继续输入以筛选列表，按回车键即可完成插入。

  • 适用场景：当您明确知道需要使用的标签，追求极致的编写速度时，此方法效率最高。它是高级用户和脚本编写者的首选。

图：Yakit 编辑器代码自动补全功能演示

4.4.2.2 Fuzztag 的双重角色：数据生成与数据处理​

从功能角度看，所有的 Fuzztag 可被归为两大类：生成型标签与处理型标签。理解这种分类是掌握 Fuzztag 的关键，它有助于您在构造测试用例时，清晰地规划数据流：从何处生成原始数据，经过何种处理，最终形成怎样的测试载荷。

为了便于实践，用户可以利用 Yakit 导航栏中的“安全工具”->“Fuzzer”->“Fuzztag 调试器”快速验证和学习这些标签。如下图所示，您可以在输入框中编写 Fuzztag，实时查看其渲染结果，这是掌握本节内容最有效的方法。

图：Yakit Fuzztag 数据生成与展示界面

标签的数量非常多，用户可以随时通过4.4.2.1中的Fuzztag助手进行查阅和快速学习。

生成型标签：作为数据的源头​

这类标签的核心职责是“无中生有”，根据预设规则创造新的数据。它们是模糊测试中各种 Payload 的直接来源。

  • 定义：用于API参数的爆破（如用户ID、订单号）、字典攻击（用户名、密码）、随机化输入以探索边界条件或绕过缓存等。

  • 典型示例：

    • {{int(1-100)}}：生成从 1 到 100 的整数序列。

    • {{randstr(10)}}：生成一个长度为 10 的随机字符串，例如结果：SmcbJjrvXM。

    • {{uuid()}}：生成一个标准的 UUIDv4 值。

    • {{x(pass_top25)}}：从内置或自定义字典 user_top100 中依次读取条目。

图：生成型标签数据源与结果展示

  • 应用场景：用于参数遍历、ID 枚举、字典爆破、随机化输入绕过缓存等。

下表精选了常用的生成型标签，您可以直接在 Fuzztag 调试器中实践，以加深理解。

处理型标签：作为数据的管道与过滤器​

与生成型标签不同，处理型标签扮演的是数据“处理器”的角色。它们一般来说接收一个输入值，对其进行转换、编码、加密或格式化等操作，然后输出处理后的结果。

  • 定义：接收一个或多个参数（参数可以是静态值或其他标签的输出），并对其进行加工处理的标签。一般用于构造加密的 Token 或签名、绕过 WAF 的编码检测、处理包含特殊字符的参数、满足特定的数据格式要求等。

  • 典型示例：

    • {{md5(admin)}}：计算字符串 "admin" 的 MD5 值，计算值为21232f297a57a5a743894a0e4a801fc3

    • {{base64enc(test)}}：对字符串 "test" 进行 Base64 编码。

    • {{urlenc(a=b)}}：对字符串 "a=b" 进行 URL 编码。

下表精选了常用的处理型标签，覆盖了编码、哈希和字符串操作等常见场景。

特殊标签：codecflow 与 param 的高级应用​

在前序小节中，我们已经掌握了 Fuzztag 的两大基本类别：作为数据源头的生成型标签和作为数据管道的处理型标签。这解决了单一请求内的数据构造问题。然而，要应对现代 Web 应用的复杂性和有状态性，我们还需要更强大的指令来实现跨模块功能联动和跨请求状态管理。

本节将深入剖析 Fuzztag 体系中两个至关重要的指令级标签：{{codecflow}} 和 {{param}}。它们将模糊测试的能力从无状态的数据操作，提升到了模拟真实业务逻辑的高度。通过学习本节，您将掌握如何将 Codec 模块的复杂处理能力无缝集成到 Fuzzing 流程中，以及如何构建能够模拟用户登录、会话保持等有状态行为的自动化测试序列。

{{codecflow}}：联动 Codec 模块实现复杂数据变换​

{{codecflow}} 的核心设计目标是解决一个常见的工程痛点：当一个数据需要经过一系列复杂、非标、多步骤的变换时（例如，先进行 URL 解码，再进行 Base64 解码），单纯依靠处理型标签的层层嵌套 {{base64dec({{urldec(...)}})}} 会变得冗长、易错且难以维护。{{codecflow}} 指令通过调用在 Codec 模块中预先定义并保存的“配方”（Recipe），优雅地解决了这一问题。

案例驱动：创建并使用一个解码配方​

为了具象化理解其工作流程，我们以一个实际案例——“对一个经过 Base64 和 URL 双重编码的数据进行解码”——来展示 {{codecflow}} 的威力。

第一步：在 Codec 模块中创建并保存配方

图：Yakit创建解码配方保存顺序

如上图所示，我们在 Yakit 的 Codec 模块中进行操作。首先，从左侧的“解码”分类中，依次将“URL 解码”和“base64解码”拖拽到右侧的“编解码顺序”工作区。然后，点击保存图标，将这个由两个步骤组成的流水线命名为 url-base64-decode 并保存。此后，这个配方就成为了一个可被全局调用的、可复用的处理逻辑。

第二步：在 Fuzzer 中调用已保存的配方

图：Yakit 解码配方与模糊标签使用界面

在 Fuzztag 调试器或 Web Fuzzer 的请求模板中，我们可以通过以下语法来调用刚刚创建的配方：

{{codecflow(url-base64-decode|%61%47%56%73%62%47%38%74%64%32%39%79%62%47%51%3d)}}

在这个指令中：

  • url-base64-decode 是我们保存的配方名称。

  • | 是一个分隔符，用于区分配方名和待处理的数据。

  • %61...3d 是需要被处理的原始输入数据。

当 Fuzzing 引擎执行此标签时，它会将输入数据 %61...3d 先进行 URL 解码得到 aGVsbG8td29ybGQ=，再将此结果进行 Base64 解码，最终得到清晰的明文 hello-world，并用此结果替换整个标签。

如果你忘记了你刚刚保存的codecflow的规则名，可通过“历史存储”查看和重新使用来找回名字

图：解码配方历史存储与清空功能

内部工作原理回顾​

正如我们在 2.3.5 章节中深入探讨的，{{codecflow}} 的执行依赖于一条严谨的内部调用链路，确保了 Fuzzing 引擎与 Codec 模块的精确协同：

  1. Fuzzer 引擎解析： Web Fuzzer 模块在准备发送 HTTP 请求前，解析模板中的 {{codecflow(flow_name|content)}} 语法。

  2. 识别 Codec 调用指令： 解析器识别出 flow_name（配方名）和 content（待处理数据）。

  3. 发起内部调用： Fuzzing 引擎向 Codec 模块发起一个内部调用，请求执行名为 flow_name 的配方，并将 content 作为输入。

  4. 执行配方流： Codec 模块加载并按顺序执行预设的数据转换操作，并将最终结果返回。

  5. 载荷替换与发送： Fuzzing 引擎用返回的结果替换整个 {{codecflow(...)}} 标签，构建最终请求并发送。

{{param}}：在规则与序列中实现参数化与状态管理​

{{param(...)}}（可简写为 {{p(...)}}）是实现状态管理（State Management）和配置复用的关键指令。它允许我们在 Fuzzing 任务的执行期间定义、存储和引用变量，其应用场景在“规则”和“序列”模式下各有侧重。

图：Yakit 规则与序列中的变量配置界面

在“规则”中定义静态变量与任务级常量​

如上图左侧所示，在 Web Fuzzer 的“规则”配置界面，可以通过“设置变量”功能定义一个变量。例如，设置一个名为 nuclei 的变量，其值为 fuzztag。

此变量的作用域是当前整个 Fuzzing 任务，其行为类似于一个全局常量。在请求模板的任何位置，都可以通过 {{param(nuclei)}} 来引用它的值 fuzztag。这种方式非常适用于需要多处重复使用同一固定值（如一个特定的 User-Agent、一个基础路径或一个 API-Key）的场景，便于统一修改和维护，提升了测试配置的可读性。

在“序列”中实现动态状态传递​

更详细“序列用法”详见本章4.8小节。

{{param}} 的真正威力在测试有状态应用时得以淋漓尽致的体现。在“序列”测试模式下，它成为了连接多个请求步骤、传递动态数据的桥梁。

如上图右侧所示，在一个由多个 Step 组成的序列化测试任务中：

  1. 我们可以在 Step [0] 的“数据提取器”中，配置规则（例如，使用正则表达式）从服务器的响应体中提取一个动态生成的值，如 session_id 或 CSRF-Token。

  2. 然后，将这个提取到的值存入一个名为 cookie 的变量中。

  3. 随后，在 Step [1] 乃至后续所有步骤的请求配置中（例如，在 Cookie 或自定义 Header 头中），我们就可以通过 {{param(cookie)}} 来引用这个从上一步动态获取到的值。

这一机制是实现对需登录认证、有会话保持、有反跨站请求伪造令牌等现代 Web 应用进行深度自动化测试的技术基石。它完美解决了测试流中“承上启下”的数据依赖问题，使得 Yakit 能够精确模拟真实用户的、跨越多个请求的完整业务流程。

核心联动：嵌套与流式处理​

Fuzztag 最强大的能力在于将生成型标签和处理型标签进行嵌套。这种组合不仅是简单的单次数据转换，更是构建了一个强大的流式处理管道（Streaming Pipeline）。数据可以由一个生成型标签产生一个序列，序列中的每一个元素再依次流经后续的处理型标签，最终形成一批高度动态和复杂的测试载荷。

其执行流程严格遵循“由内向外”和“迭代处理”的原则。以下案例演示了如何为一组数字ID生成对应的、大写的MD5哈希值，这在测试越权漏洞时非常常见。

案例：{{upper({{md5({{int(1-5)}})}})}}

这个表达式的最终输出并非单个值，而是一个包含五个结果的列表，因为内层的 {{int(1-5)}} 标签生成了一个数据流。

输出为：

C4CA4238A0B923820DCC509A6F75849B
C81E728D9D4C2F636F067F89CC14862C
ECCBC87E4B5CE2FE28308FD9F2A7BAF3
A87FF679A2F3E71D9181A67B7542122C
E4DA3B7FBBCE2345D7772B0674A318D5

执行流程解析：

  1. 内层生成（数据流源头）: 最内层的 {{int(1-5)}} 首先执行。它并非只生成一个数字，而是创建了一个包含 1, 2, 3, 4, 5 的数据序列。这个序列成为了整个处理管道的输入源。

  2. 迭代执行（流式处理）: Fuzztag引擎会遍历 {{int(1-5)}} 生成的每一个元素，并将其送入外层的处理管道 {{upper({{md5(...)}})}} 中独立执行。

    • 第一次迭代:

      • 输入为 1。

      • {{md5(1)}} 计算得出 c4ca4238a0b923820dcc509a6f75849b。

      • {{upper(...)}} 将其转换为 C4CA4238A0B923820DCC509A6F75849B。

    • 第二次迭代:

      • 输入为 2。

      • {{md5(2)}} 计算得出 c81e728d9d4c2f636f067f89cc14862c。

      • {{upper(...)}} 将其转换为 C81E728D9D4C2F636F067F89CC14862C。

    • ... 后续迭代以此类推，直到序列中的所有元素处理完毕。

通过这种灵活的嵌套与流式处理机制，用户可以用声明式的方式，将数据生成、字典加载、多重编码/加密等复杂流程优雅地组合在一起，为API模糊测试、漏洞验证等场景批量生成高度定制化的Payload，极大地提升了安全测试的深度和广度。

4.4.2.3 控制渲染过程：同步渲染::sync 与随机化渲染::dyn​

Fuzztag 的强大不仅体现在数据生成与处理能力上，还体现在其对渲染过程的精细控制。通过::sync和::dyn标签，用户可以自定义生成器的行为，满足特定的测试需求。本节将详细介绍这两种标签的功能、实现原理及应用场景，并结合示例说明如何在实际测试中有效利用它们。

同步渲染标签：sync tag​

定义：::sync标签用于将多个动态标签的生成过程绑定为同步执行，确保它们在每次迭代时生成的数据保持一致。这在需要多个参数保持关联关系的测试场景中尤为重要，例如测试需要配对的 ID 和 Token、用户名密码组合。

使用方式：

  • 普通标签的渲染独立进行，例如{{int(1-3)}}{{int(1-3)}}会生成组合如 11, 12, 13, 21, 22, 23, 31, 32, 33，每个标签独立生成数据。

  • 同步标签通过在函数名后添加 :: 后跟一个自定义标签名来实现同步，其中标签名需符合正则表达式 ^[a-zA-Z_][a-zA-Z0-9_:-]*$（例如 number、user_id 等）。对于相同标签名的标签，其渲染过程会同步执行，确保输出一致。

  • 示例：{{int::number(1-3)}}{{int::number(4-6)}} 会生成 14, 25, 36，因为两个标签共享 ::number 标签，同步生成匹配的数值对。

工作原理：

  • 当一个动态标签被标记为::sync（如 ::number），Fuzzer 引擎会将其与其他同名 ::sync 标签的生成器绑定。

  • 在生成过程中，引擎会同时触发所有同名标签的生成器，确保它们的输出在同一轮次内一致。

  • 生成结果自底向上传播时，同步标签的输出被统一组合并传递至父节点，避免数据错位。

  • 约束：同步标签不能应用于流控制标签，且不能同步父子关系的标签，以避免逻辑冲突。

应用场景：

  • 测试需要配对的参数（如 ID 和签名）。

  • 验证多字段关联的业务逻辑（如订单 ID 和支付 Token）。

  • 确保测试用例中多个动态参数的同步性。

随机化渲染标签：dyn tag​

定义：::dyn 标签强制生成器在每次迭代时重新执行生成逻辑，忽略缓存机制，适用于需要动态生成随机或实时数据的场景，例如随机字符串、时间戳等。

工作原理：

  • 标记为 ::dyn 的标签在每次执行时都会重新生成数据，而不是从缓存中读取。这种行为适合动态性要求高的测试场景。

  • 生成结果同样自底向上传播，与其他节点的输出组合形成最终请求。

应用场景：

  • 测试防重放机制（需要每次生成不同的随机值）。

  • 模拟动态输入（如时间戳、随机 Token）。

注意事项：

  • ::dyn应用在高频计算的tag上会大幅度增加计算开销，建议仅在必要时使用。

  • ::sync标签名需符合正则^[a-zA-Z_][a-zA-Z0-9_:-]*$并谨慎命名，避免意外绑定无关标签。

通过::sync和::dyn标签，Fuzztag 提供了对生成过程的精细控制，使用户能够灵活应对复杂的测试需求，提升了安全测试的效率和覆盖面。

4.4.3 转义问题与边界情况​

我们在之前的章节中了解了 Fuzztag 如何通过嵌套组合实现强大的数据生成能力。然而，当我们需要生成的数据本身就包含 Fuzztag 的语法关键字时，问题就变得复杂起来。本节将深入探讨 Fuzztag 的转义机制和解析边界，确保用户能够精确控制载荷的每一个字符，这对于构造针对特定解析器（如JSON、XML、GraphQL）的测试用例至关重要。

本章的核心命题在于解析优先级的理解与字符转义的工程实践。我们将阐明 Fuzztag 解析器如何区分语法与字面量，并提供在不同上下文中注入特殊字符的有效方法。

字面量与语法的冲突​

Fuzztag 的解析器依赖于一组特殊的字符序列来识别和执行指令，这些序列包括 {{、}}、( 和 )。当这些字符作为普通文本（字面量）出现在需要处理的数据中时，就会与 Fuzztag 的语法产生冲突，导致非预期的解析行为或错误。

策略一：参数内的反斜杠转义​

在 Fuzztag 的函数参数内部，处理特殊字符 {{ 和 }} 的首选方法是使用反斜杠 \ 进行转义。解析器会将 \{{ 和 \}} 识别为字面量，而非嵌套标签的起止符。

  • 核心规则: \{{ 被解析为字符串 {{，\}} 被解析为字符串 }}。

  • 适用范围: 此转义规则仅在 Fuzztag 标签的参数区域内生效。

  • 二次转义: 如果需要生成 \{{ 本身，则应使用 \\{{。

案例：生成包含 {{ 和 }} 的字符串

假设我们需要重复生成三次 {{ 字符串，可以根据下面内容设置输入

括号 () 的解析边界​

相对于 {{ 和 }}，括号 () 的处理规则相对宽松。Fuzztag 解析器在处理函数调用时，遵循“最外层匹配”原则。

  • 核心规则: 在 {{tag(...)}} 结构中，只有与最内层 {{ 匹配的最后一个 ) 才被视为函数调用的结束符。中间出现的所有 ( 和 ) 都会被当作字面量处理。

  • 实践意义: 在大多数情况下，参数内的括号无需特殊转义。

案例：生成**(或)**的字符串

假设我们需要重复生成三次(或)字符串，可以根据下面内容设置输入

策略二：上下文注入与编码绕过​

当特殊字符 {{ 或 }} 需要出现在非 Fuzztag 参数的静态上下文中（例如，HTTP 请求的Body模板中），反斜杠转义将不再适用。此时，必须采用编码绕过的思想来注入这些字符。

  • 核心思想: 使用一个能够解码为目标字符的 Fuzztag 来代替该字符本身。

  • 推荐实现: {{hexdec(...)}} 是一个理想选择，它可以将十六进制编码的字符串解码回原始字符。

    • {{ 对应 {{hexdec(7b7b)}}

    • }} 对应 {{hexdec(7d7d)}}

案例：在 JSON 载荷中构造模板注入测试语句​

假设我们需要发送一个恶意的 JSON 对象，其值包含一个待注入的模板字符串，如 {"key": "{{7*7}}"}。直接编写会因外层的 {{...}} 导致 Fuzztag 解析错误。

正确的构造方式如下：

{
    "key": "{{hexdec(7b7b)}}7*7{{hexdec(7d7d)}}"
}

执行流程：

  1. Fuzztag 引擎扫描整个请求模板。

  2. 它发现并执行了两个 hexdec 标签。

  3. {{hexdec(7b7b)}} 被执行，其输出结果为字符串 {{。

  4. {{hexdec(7d7d)}} 被执行，其输出结果为字符串 }}。

  5. 最终，发送到服务器的实际载荷被精确地重组为 {"key": "{{7*7}}"}，成功绕过了本地 Fuzztag 解析器的限制。具体案例用户可直接通过下面查看

图：Yakit Web Fuzzer JSON载荷模板注入示例

注入非可见字符​

在前一节中，我们解决了如何在 Fuzztag 语法中处理 {{、} 等可见的特殊字符。然而，在真实的网络攻防场景中，对非可见字符（如空字符 \x00、回车换行 CRLF）的精确控制同样是攻击能否成功的关键。这些字符在协议层面或特定语言的解析器中具有特殊含义，能够导致截断、绕过等致命缺陷。

本小节目的是说明非可见字符的生成方法与其在真实漏洞场景中的应用。我们将系统性地介绍 Fuzztag 提供的多种注入非可见字符的途径，并通过一个经典的PHP文件上传漏洞案例，展示其在安全测试中的巨大威力。

生成方式一：快捷标签​

为了提升便利性，Fuzztag 内置了一系列用于生成常用非可见字符的快捷标签。这种方式代码可读性高，意图明确，是首选方案。

  • {{null}}：生成空字符 NULL (\x00)。

  • {{crlf}}：生成 CRLF (\r\n)，常用于HTTP协议的头部注入和请求走私。

生成方式二：动态解码​

当需要生成的字符没有对应的快捷标签，或者需要以更编程化的方式构造载荷时，可以使用解码标签。这种方式提供了极高的灵活性。

  • {{hexdec(...)}}：将十六进制编码的字符串解码为原始字节。例如，{{hexdec(00)}} 等效于 {{null}}。

  • {{b64dec(...)}}：将 Base64 编码的字符串解码为原始字节。

案例驱动：PHP 空字符截断漏洞利用​

原理剖析: PHP 的底层实现部分由 C 语言编写，而 C 语言处理字符串时，通常以空字符 \x00 作为字符串的结束标记。当一个包含空字符的字符串（如文件名）被传入某些未做严格处理的PHP函数时，函数可能只认读到空字符之前的部分，导致安全校验逻辑被截断绕过。

场景: 一个允许用户上传 .jpg、.png 文件的Web应用，其后端通过检查文件名后缀来判断文件类型。

攻击目标: 上传一个名为 shell.php 的webshell，并绕过后缀名检查。

载荷构造: 我们可以构造一个文件名 shell.php{{null}}.jpg。当 Fuzztag 执行时，{{null}} 被替换为 \x00，最终文件名变为 shell.php\x00.jpg。PHP后端在解析此文件名时，会将其视为 shell.php，而文件系统（或Web服务器）可能依然根据 .jpg 后缀进行处理，从而成功绕过校验，将PHP脚本以图片文件的名义写入服务器。

HTTP 请求包构造：

POST /upload HTTP/1.1
Host: example.com
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW

------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="file"; filename="shell.php{{null}}.jpg"
Content-Type: image/jpeg

<?php phpinfo(); ?>
------WebKitFormBoundary7MA4YWxkTrZu0gW--

通过这种方式，{{null}} 标签成为了连接 Fuzztag 能力与底层漏洞原理的关键桥梁，使得原本需要特殊工具才能实现的攻击载荷，可以用声明式的方式轻松构造。用户在 Web Fuzzer 输入后，可看到如下{{null}}高亮后的内容：

图：Yakit工具构造PHP空字符截断漏洞请求

终极方案：使用{{=和=}}处理原始文本块​

在前面的章节中，我们探讨了 Fuzztag 中标准的转义与编码机制，这些机制是处理动态数据注入的基础。然而，在面对包含复杂内嵌语法或需保持绝对字面保真度的静态数据块时，传统方法显得力不从心。本章将深入剖析 Fuzztag 的终极解决方案——原始文本块（Raw Literal Block）{{=...=}}。我们将围绕其**“解析豁免”的核心原理与“高保真载荷构造”的工程实践**两大命题展开，阐明该机制如何从根本上解决语法冲突，确保复杂载荷的精确传递，这对于高级安全测试和复杂系统集成场景至关重要。

语法与解析豁免机制​

  • 定义: {{= 为起始符，=}} 为结束符。

  • 核心规则: 当 Fuzztag 解析器遇到 {{= 时，它会暂停所有解析活动，将后续的所有字符（包括换行符、{{、}}等一切特殊字符）作为单一的字符串进行缓冲，直到遇到=}}为止。

这一机制的本质是给予用户一个临时的解析豁免权，确保所见即所得。

案例一：嵌入包含 Fuzztag 语法的代码片段​

在协同工作或进行多层系统测试时，我们常需要发送一段本身就是模板代码的载荷，让目标系统进行二次解析。例如，发送一个包含 {{variable}} 的字符串，意图是让接收方来替换 variable。

如果直接在 Fuzztag 中编写，本地引擎会尝试解析 {{variable}}，这并非我们的本意。

  • 错误的方式: {"payload": "{{variable}}"}

    • 后果: 本地 Fuzztag 引擎会试图在本轮请求的上下文中查找并替换名为 variable 的标识符，如果未定义则可能报错或输出为空，导致发送的载荷不符合预期。

  • 正确的构造:

{{={"payload": "{{variable}}"}=}}
  • 最终输出结果：
{"payload": "{{variable}}"}

在这个案例中，{{=...=}} 保护了内部的 JSON 结构及其值 {{variable}} 不被当前 Fuzztag 引擎解析。它确保了模板字符串作为一个原始文本被发送出去，供下游系统接收和处理。

案例二：构造高保真度的复杂攻击载荷​

在高级安全测试，尤其是服务端模板注入（SSTI）漏洞的利用场景中，一个核心挑战是构造“载荷中的载荷”（Payload-within-a-Payload）。这意味着我们发送的数据本身就包含特殊语法，旨在由目标服务器的某个组件（如模板引擎）进行二次解析。在此类场景下，确保载荷在传输过程中的完整性和精确性，即“载荷保真度”，是测试成功的关键。

问题的本质在于本地 Fuzztag 引擎与目标系统之间可能存在的语法冲突。例如，当我们需要向目标服务器提交一个包含模板指令 {{7*7}} 的 JSON 数据时，本地 Fuzztag 解析器会优先尝试解释并执行这个指令，这违背了我们希望将其作为原始字符串传递的初衷。

传统规避方案：手动编码与转义​

在没有原始文本块机制的情况下，技术人员必须手动对载荷中的特殊字符进行编码，以“欺骗”本地解析器。这种方法的原理是通过将语法关键字（如 { 和 }）替换为其十六进制编码的等价物，绕过第一层解析，待数据发送至服务端前再由 Fuzztag 的 hexdec() 函数将其还原。

实现方式：

{
  "key": "{{hexdec(7b7b)}}7*7{{hexdec(7d7d)}}"
}

  • 工作流解析：

    1. Fuzztag 引擎读取到 {{hexdec(7b7b)}}。

    2. hexdec 函数执行，将十六进制 7b 解码为 ASCII 字符 {。

    3. 同理，{{hexdec(7d7d)}} 被解码为 }。

    4. 最终拼接成字符串 {{7*7}}。

方案评估： 此方法虽然可行，但其弊端显而易见。首先，它严重降低了载荷的可读性，使得调试和维护变得异常困难。其次，对于包含大量特殊字符或多层嵌套的复杂载荷，手动编码的过程极其繁琐且极易出错。这种方法在工程实践中扩展性差，不符合高效、可靠的测试原则。

推荐方案：使用原始文本块保证所见即所得​

{{=...=}} 原始文本块为此类场景提供了根本性的解决方案。它通过创建一个“解析豁免区”，指示 Fuzztag 引擎暂停对该区域内所有内容的解析和转义，将其视为一个单一、不可变的字面量。

{{={
  "key": "{{7*7}}"
}=}}

  • 工作流解析：

    1. Fuzztag 解析器遇到起始标记 {{=。

    2. 解析器进入“原始文本模式”，停止对后续所有字符（包括换行符、引号、{{ 和 }}）的任何语法分析。

    3. 它持续缓冲所有字符，直到匹配到结束标记 =}}。

    4. 整个被包裹的文本块（从 { 到 }，包含所有换行和缩进）被原封不动地作为最终输出。

最终生成的 HTTP Body 对比： 两种方法最终生成的 HTTP 请求体完全相同，均为：

{
  "key": "{{7*7}}"
}

通过上述对比，{{=...=}} 原始文本块的工程价值得以彰显。它不仅是语法上的便利，更是保障复杂测试用例健壮性和可维护性的关键机制。通过赋予用户临时的“解析豁免权”，它从根本上解决了由多层解析系统引发的语法冲突问题。在构造如 GraphQL 复杂查询、XML-RPC 调用、或针对特定协议的模糊测试用例时，采用原始文本块是保证载荷精确性、提升测试效率的首选方案。后续章节我们将探讨如何将其与 Fuzztag 的其他功能结合，构建更为强大的自动化测试流程。

4.4.4 动态可编程 Payload：热加载标签​

在此前的章节中，我们讨论的 Payload 生成方式，如 {{file}} 或 {{range}}，本质上属于声明式配置。用户指定数据源或范围，由 Fuzzer 引擎进行迭代。然而，在面对需要实时计算、加密签名或遵循复杂业务逻辑的测试场景时，这种预设的、静态的数据集便显得力不从心。为了突破这一瓶颈，Web Fuzzer 引入了革命性的热加载标签，将图灵完备的 Yak 语言嵌入 Payload 生成流程，实现了从“数据填充”到“代码生成”的跃迁。

4.4.4.1 核心原理与函数范式：​

热加载标签的核心是 {{yak(...)}} 语法，它在请求模板中充当了调用自定义 Yak 代码的入口。

  • 调用语法：{{yak(functionName|paramString)}}或免参数直接调用{{yak(functionName)}}

    • yak(...): 专有关键字，声明这是一个热加载动态标签。

    • functionName: 指定在“热加载代码”区域中定义的 Yak 函数名。

    • |: 分隔符，用于区分函数名和传递给它的参数(如果没有参数，可省略)。

    • paramString: 传递给函数的参数。请特别注意：无论在这里填写多少个用逗号分隔的参数（如 arg1,arg2,arg3），它们都会被合并成一个单一的字符串 "arg1,arg2,arg3"，然后传递给 Yak 函数。在函数内部，您需要自行解析这个字符串，例如使用 str.Split(paramString, ",") 来获取独立的参数列表。这种设计旨在为处理复杂或包含特殊字符的输入提供最大的灵活性。

在 Fuzz 任务执行时，引擎会通过检查您在热加载代码区所定义函数的参数数量，来决定采用两种截然不同的执行模式之一：

  1. 同步返回模式 (Synchronous Return): 单参数函数

    • 函数定义: func(params string)

    • 工作机制: 当引擎检测到您的函数只定义了一个参数时，它会进入同步返回模式。引擎会将标签中的 paramString 完整地传递给这个参数，然后等待函数执行完毕。函数必须一次性返回一个最终结果，该结果可以是单个字符串，也可以是一个字符串数组 ([]string)。引擎会根据返回值的类型，或直接替换模板，或进行迭代发包。我们将在 4.4.4.2 节中详细探讨此模式。

  2. 异步产出模式 (Asynchronous Yield): 双参数函数

    • 函数定义: func(params string, yield func(string))

    • 工作机制: 当引擎检测到您的函数定义了两个参数时，它将自动切换到强大的异步产出模式。引擎会将标签中的 paramString 作为第一个参数传入，并自动注入一个内部的 yield 回调函数作为第二个参数。无论您在代码中为第二个参数取什么名字（尽管约定俗成为 yield），其作用都是产出 Payload。在函数体内，您可以随时调用 yield(payload) 来逐个地、实时地产出一个结果，每调用一次，Fuzzer 就会立即使用该结果构建并发送一个请求。这种流式处理机制将在 4.4.4.3 节中深入讲解。

4.4.4.2 同步返回模式：构建与转换数据集​

同步返回模式是快速处理数据转换、组合生成等场景的理想选择，其核心在于“一次计算，一次返回”。

我们以一个简单的需求为例：为给定的输入字符串添加一个固定的前缀。

编写热加载函数（返回单字符串）​

首先，我们需要在“热加载代码”编辑器中定义处理逻辑。如下图所示，我们创建了一个名为 appendPrefix 的函数，它接收一个参数 data，并返回一个拼接了固定前缀的新字符串。

// 定义一个函数，用于为输入数据添加特定前缀
func appendPrefix(data) {
    return "string-prefix-is-me====" + data
}

图：Yakit 热加载函数编写界面及 Go 代码示例

在请求模板中调用​

接着，我们在请求报文模板中，使用 {{yak(...)}} 语法来调用这个刚刚定义的函数。在这里，我们希望为字符串 abc 添加前缀。

{{yak(appendPrefix|abc)}}

这个标签精确地表达了“调用 appendPrefix 函数，并把 abc 作为第一个参数传给它”的意图。从上图中可以直接编辑预览。

  1. 调试与验证

在正式发起大规模 Fuzz 之前，Yakit 提供了“调试执行”功能，可以即时验证热加载标签的输出是否符合预期。点击“调试执行”，系统会弹出一个窗口，清晰地展示该标签经过 Yak 引擎解释执行后的最终结果。

图：Yakit热加载代码调用与结果展示

如上图所示，输出结果与我们的预期完全一致。这个简单的案例完整地演示了从 定义逻辑 -> 模板调用 -> 运行时生成 的全过程。

通过返回数组实现一对多 Payload 生成​

前面的案例演示了最基础的一对一转换，即一个函数调用返回一个字符串 Payload。然而，同步返回模式的另一个重要能力在于其一对多的生成能力。通过让函数返回一个字符串数组 ([]string)，您可以将一个简单的函数调用转变为一个强大的、动态的 Payload 迭代器。

此模式的核心在于：当热加载函数返回一个数组时，Fuzzer 引擎不会将整个数组作为单个值注入，而是会自动对数组中的每一个元素进行迭代，为每个元素生成并发送一个独立的 HTTP 请求。

我们通过一个具体的场景来解析这个过程：将一个逗号分隔的字符串解析为多个独立的 Payload。

  • 定义需求与调用标签： 假设我们的目标是将参数 orderId 的值在 a,b,c,d 四个值中进行遍历测试。为此，我们在请求模板中构造如下的调用标签：
GET /bruteplayground/by-order-id?orderId={{yak(handleCommaSplit|a,b,c,d)}} HTTP/1.1
  • 编写热加载函数： 为了响应上述调用，我们在“热加载代码”区域定义一个单参数函数 handleCommaSplit。该函数的核心任务是接收参数字符串，并使用 str.Split 函数将其分割成一个字符串数组并返回。
// 函数仅有一个参数，符合同步返回模式。
// 它接收一个字符串，但返回一个字符串数组，这将触发引擎的迭代机制。
func handleCommaSplit(params) {
    // 将 "a,b,c,d" 切割为 ["a", "b", "c", "d"]
    return str.Split(params, ",")
}
  • 结果解析与引擎行为： 当 Fuzz 任务启动时，引擎执行 handleCommaSplit("a,b,c,d")，并收到返回值——一个包含四个元素的数组 ["a", "b", "c", "d"]。此时，引擎的迭代机制被激活：它会依次取出数组中的每个元素，生成四个独立的请求，其 orderId 参数值分别为 a、b、c 和 d。

图：Yakit Web Fuzzer通过handleCommaSplit生成多组Payload

这个案例清晰地展示了同步返回模式的强大之处：用户只需编写简单的逻辑来生成一个数据集（数组），即可将繁琐的迭代任务完全交给 Fuzzer 引擎自动完成。这为动态生成复杂、批量的测试用例提供了极大的便利。

4.4.4.3 异步模式：流式实时生成​

我们之前探讨了同步返回模式，其核心是“一次性计算并返回完整数据集”。这种模式虽然强大，但在处理需要长时间计算、外部依赖或无法一次性载入内存的超大规模数据集时，会显得力不从心。为了克服这些限制，Fuzzer 设计了更为先进的异步产出模式 (Asynchronous Yield)。

本节将深入剖析异步模式的运行机制。该模式的本质是将 Payload 的“生产”与“消费”解耦，允许热加载函数像一个数据流一样，持续不断地、实时地向 Fuzzer 引擎“喂送”Payload。这不仅极大地提高了效率，也为实现复杂的、与时间相关的测试场景提供了可能。

核心机制：yield 回调函数​

异步模式的启用条件非常明确：当且仅当您的热加载函数定义了两个参数时，引擎会自动切换到此模式。

  • 函数定义: func(params string, yield func(string))

    • params: 第一个参数，与同步模式一样，接收来自 {{yak(...)}} 标签的参数字符串。

    • yield: 第二个参数，这是由 Fuzzer 引擎在调用时自动注入的一个内部回调函数。您可以在函数体内的任何地方、任何时间调用 yield(payload)。每调用一次，该 payload 就会被立即发送到 Fuzzer 的任务队列中，准备构建并发送请求，而您的函数可以继续执行后续逻辑，无需等待。

实践案例：实时生成带时间延迟的 MD5 值​

为了直观地感受异步模式的流式特性，我们构建一个案例：每隔 0.5 秒生成一个数字的 MD5 值，并将其作为 Payload 产出。

  • 编写热加载函数 (双参数) 在“热加载代码”区域，我们定义一个 yieldMD5Range 函数。由于它有两个参数 (params 和 yield)，引擎将采用异步模式。注意，在此案例中，我们不需要外部输入，因此 params 参数虽然必须存在，但可以不使用。
// 函数定义了两个参数，自动启用异步产出模式
func yieldMD5Range(params, yield) {
    // 循环生成 5 个 Payload
    for i = 0; i < 5; i ++ {
        // sleep 用于模拟耗时操作，例如复杂的加密计算或API调用
        sleep(0.5) 
        
        // 调用 yield() 将 Payload 实时推送到 Fuzzer 引擎
        // 函数会继续执行，不会在此处阻塞
        payload := "i:" + string(i) + " md5:" + codec.Md5(i)
        yield(payload)
    }
}

  • 在请求模板中调用 在请求中，我们使用 {{yak(yieldMD5Range)}} 来调用此函数。由于函数本身不依赖输入，我们无需提供参数。
GET /bruteplayground/by-order-id?orderId={{yak(yieldMD5Range)}} HTTP/1.1

行为剖析：调试执行 vs. Fuzz 执行

  • 调试执行 (Debug Execution): 如果您点击“调试执行”按钮，会观察到一个有趣的现象：界面会“卡住”大约 2.5 秒 (5 * 0.5秒)，然后一次性显示出所有 5 个结果。这是因为“调试”功能的目的是验证函数的完整输出，它会等待整个函数执行完毕，收集所有通过 yield 产出的值，最后统一展示。这是一种为了调试便利而设计的同步化模拟。

  • Fuzz 执行 (Fuzz Execution): 当您点击“发送请求”启动真正的 Fuzz 任务时，异步模式的威力才会完全显现。引擎的行为将变为：

    1. 调用 yieldMD5Range 函数。

    2. 函数开始循环，等待 0.5 秒。

    3. 第一次调用 yield()，产出 i:0 的 Payload。Fuzzer 引擎立即接收到此 Payload，构建第一个请求并发送。

    4. 与此同时，yieldMD5Range 函数并未结束，继续执行循环，等待第二个 0.5 秒。

    5. 第二次调用 yield()，产出 i:1 的 Payload。Fuzzer 引擎再次立即构建第二个请求并发送。

    6. ……以此类推，直到函数执行完毕。

您会在结果列表中看到，每隔约 0.5 秒就会出现一条新的测试结果，而不是等待 2.5 秒后一次性出现。

图：Yakit 实时生成带延迟的 MD5 值演示

通过这个案例，我们清晰地看到，异步产出模式将 Payload 的生成过程从一个“批处理任务”转变为一个“数据流”，是应对复杂动态场景、提升 Fuzz 效率的终极武器。

4.4.4.4 嵌套调用与组合范式​

在深入理解了同步与异步两种基本模式后，我们必须揭示热加载标签一个至关重要且极具颠覆性的特性：嵌套与组合。Fuzzer 的引擎并非孤立地处理每一个标签，而是遵循着严格的由内向外的求值顺序，这使得不同功能的 Fuzz 标签可以像乐高积木一样自由拼接。

这一设计思想的直接体现是，{{yak(...)}} 标签的参数位可以接受任何其他 Fuzz 标签的输出。例如，下面这个看似简单的表达式，却蕴含着强大的组合能力：

{{yak(yourFuncname|{{int(1-10)}})}}

引擎在解析时，会首先执行内部的 {{int(1-10)}}，将其产出（如 "1", "2", ..., "10"）作为字符串，再传递给外部的 yak 标签所调用的 yourFuncname 函数。这不仅仅是一个功能，它代表了一种组合范式：将“数据源”（如{{int}}, {{file}}）与“数据处理逻辑”（{{yak}}）彻底解耦。这种能力将单一的函数调用提升为可编排的数据处理流水线，让测试用例的构造拥有了近乎无限的灵活性与表达力。

4.4.4.5 核心价值与范式总结​

在前文中，我们通过具体的案例，分别剖析了热加载标签的同步返回模式与异步产出模式。本节将对这两种核心范式进行归纳总结，从更高维度阐述 {{yak(...)}} 标签如何将模糊测试从“静态数据填充”提升至“动态代码生成”的全新高度，并为后续的深入实践提供方向指引。

热加载标签 {{yak(...)}} 是 Fuzzer 工具从声明式配置迈向命令式编程的决定性一步。它通过对函数签名的智能识别，提供了两种截然不同但相辅相成的生成范式，从根本上解决了传统静态字典或简单序列生成器所面临的局限性。

  1. 同步返回模式 (Synchronous Return)：此模式的核心是数据转换与批量构造。它将函数视为一个纯粹的数据处理器，接收输入、一次性完成计算，然后返回完整的结果集。通过巧妙地返回数组 ([]string) 来触发引擎的一对多迭代，该模式是实现复杂数据组合、编码转换、或基于少量输入派生大量测试用例的利器。它高效、直观，是替代静态字典进行精细化迭代的首选方案。

  2. 异步产出模式 (Asynchronous Yield)：此模式的本质是流式处理与实时解耦。它将函数转变为一个数据生产者，通过 yield 回调机制，将 Payload 的生产与引擎的消费彻底分离。这完美解决了三大核心痛点：耗时计算（如复杂加密）、外部依赖（如 API 调用）以及超大规模数据集的内存瓶颈。该模式是应对需要维持状态、与时间相关的实时交互场景的终极解决方案。

从根本上说，{{yak(...)}} 标签将模糊测试的核心从“填充什么数据”提升到了“如何生成数据”的战略高度。它赋予了安全工程师利用图灵完备的 Yak 语言，为特定的业务逻辑、加密算法或协议状态机量身定制 Payload 生成逻辑的能力。这种从“数据消费者”到“逻辑创造者”的角色转变，极大地拓展了模糊测试的深度和广度。

后续学习方向：我们强烈建议您亲手实践这两种模式，并尝试构建您自己的工具函数库。例如，编写一个用于生成带时间戳和签名的 JWT 的同步函数，或者一个从外部接口或者信息源实时拉取测试用例的异步函数。熟练掌握热加载标签，您将能够从容应对以往几乎无法自动化测试的复杂应用场景，真正将模糊测试这项技术的效能发挥到极致。

4.4.5 实战场景：使用 Web Fuzzer 进行参数遍历与爆破​

前续章节（4.4.3）我们深入探讨了 Fuzztag 中转义机制与原始文本块的原理，解决了如何精确构造单个复杂载荷的问题。然而，安全测试的威力往往体现在规模化与自动化上。本章将承接载荷构造的知识，将其应用于大规模自动化测试场景，核心是展现如何利用 Web Fuzzer 模块，将我们精心设计的载荷模板转化为成千上万个实际的测试请求。本节将围绕两大核心命题展开：一是阐述自动化遍历与爆破的测试方法论，二是深入剖析 Yakit Web Fuzzer 在典型业务场景下的工程实践，旨在帮助读者从“如何构造”迈向“如何规模化利用”。

4.4.5.1 核心原理：基于请求模板与载荷生成器的自动化测试模型​

在现代 Web 安全评估中，参数遍历与爆破是发现非授权访问（如 IDOR）、弱凭证和隐藏信息等漏洞的关键技术。其本质是一种基于“字典”的自动化穷举测试。Web Fuzzer 的工作模型正是这一思想的工程化实现，它将一个HTTP请求解构为两个核心部分：

  1. 静态请求模板（Request Template）：一个标准的、可成功发送的HTTP请求。其中，待测试的目标参数被替换为一个或多个 Fuzztag 占位符。

  2. 动态载荷生成器（Payload Generator）：由 Fuzztag 语法定义的规则或字典。它负责在运行时为模板中的占位符动态生成一系列测试值。

当测试启动时，Web Fuzzer 引擎会将载荷生成器产生的每一个值，依次填入请求模板的占位符中，从而生成并发送大量略有差异的请求。这种“模板 + 生成器”的模式，构成了所有模糊测试工具的底层逻辑。

4.4.5.2 实践案例一：利用 Web Fuzzer 遍历订单数据​

为了将理论付诸实践，我们将使用 Yakit 内置的靶场环境 Vulinbox 来演示一个经典的订单号遍历场景。

第一步：启动并定位实验环境​

Yakit 集成了一个自包含的漏洞测试环境——Vulinbox，为用户提供了安全、合法的练习平台。

  1. 在 Yakit 主界面，导航至右侧 工具箱 面板。

  2. 选择并启动 Vulinbox 靶场服务。

图：Vulinbox靶场启动参数配置界面

启动后，在 Vulinbox 的漏洞列表中搜索关键字“遍历”，并选择“遍历与爆破练习 - 订单详情页面（爆破 / 遍历订单号为 4 位数字 0-9999）”这一靶场。

图：Vulinbox Agent 界面展示漏洞筛选与订单详情页面

第二步：捕获请求并构造测试模板​

进入靶场页面后，系统会展示一个示例请求。这是我们构造请求模板的基础。

  1. 将页面显示的原始 HTTP 请求（GET /bruteplayground/by-order-id?orderId=3321 HTTP/1.1 ...）完整复制。

  2. 切换到 Web Fuzzer 模块，将复制的内容粘贴到请求编辑区。

  3. 定位到核心参数 orderId=3321，将其修改为 Fuzztag 动态载荷生成器：orderId={{int(0-9999)}}。

图：Yakit界面展示包含整数模糊测试的HTTP请求构造

这里的 {{int(0-9999)}} 是 Fuzztag 的内置函数，其作用是生成一个从 0 到 9999 的整数序列。通过这一步，我们就完成了一个从静态请求到动态测试模板的转换。

第三步：执行测试与结果分析​

配置完成后，点击 发送 按钮启动测试。Web Fuzzer 后端引擎会立即开始工作：

  1. 自动化生成：引擎以 {{int(0-9999)}} 为规则，生成 10000 个请求，每个请求的 orderId 分别为 0, 1, 2, ..., 9999。

  2. 高速发送：并发地将这些请求发送至目标靶场服务器。

  3. 实时反馈：界面右侧的响应列表会实时更新每次请求的结果，包括状态码、响应大小、响应时间以及当前使用的 Payload 值。

图：Web Fuzzer 执行测试界面与结果列表

通过对响应列表进行排序或筛选（例如，筛选出包含特定关键字的响应），测试人员可以迅速定位到所有存在的、可被访问的有效订单ID，从而验证是否存在水平越权访问漏洞（具体的筛选方式方法我们在后面章节详细讲述）。

上述基础案例完整地展示了 Web Fuzzer 的核心工作流，它将一个原本需要手动重复上万次的操作，简化为一次配置和点击，体现了自动化工具在安全测试中的巨大价值。

真实的业务场景远比此复杂。我们经常面临多参数关联爆破（如用户名和密码）、动态令牌（如 CSRF-Token）处理、以及业务逻辑强相关的数据遍历（如用户ID和其名下的订单ID必须对应）等高级挑战。这些场景无法通过简单的单参数生成器解决，需要运用 Fuzztag 更为复杂的联动与数据处理机制。接下来的章节，我们将逐一攻克这些难题。

4.4.5.3 实践案例二：时间戳与序列号结合的订单 ID​

通过之前的学习，我们掌握了利用 Web Fuzzer 对单一、独立的参数进行自动化遍历的基础工作流。然而，在真实的业务系统中，参数的结构往往更为复杂。一个常见的模式是，单个参数值本身由多个动态部分组合而成，例如，一个订单号可能由“日期前缀”与“自增序列号”拼接而成。这种场景对测试工具的载荷生成能力提出了更高的要求。接下来我们就对这种场景进行探索，用户可以通过第二个案例进入靶场：

图：订单详情页面参数爆破练习

与前例不同，这里的 orderId 参数展现出一种复合结构。

通过对请求 GET /bruteplayground/by-order-id-2?orderId=202506220001 进行分析，可以清晰地识别出 orderId 的构成规则：[日期前缀][4位序列号]。

  • 日期前缀：20250622，遵循 YYYYMMDD 格式。

  • 序列号：0001，一个从 0 开始的四位数标识。

要对此类端点进行有效测试，我们的载荷必须严格遵守此格式。这意味着在每次请求中，载荷需要由一个固定的日期部分和一个动态递增的数字部分拼接而成。

实现方案：Fuzztag 生成器的串联应用​

Fuzztag 的强大之处在于其生成器可以无缝串联，将各自的输出拼接成一个最终的字符串。这为构造复合载荷提供了极大的灵活性。

  1. 组件分解与函数选择：

    • 日期部分：对于 YYYYMMDD 格式的当前日期，我们选用 Fuzztag 的 {{date(YYYYMMdd)}} 函数。它会在每次测试任务开始时生成当天的日期字符串。

    • 序列部分：对于一个 0 到 9999 的数字序列（四位数，使用0填充），我们继续使用 {{int(0000-9999)}} 函数。

  2. 复合载荷构造： 在 Web Fuzzer 的请求模板中，我们将两个 Fuzztag 函数直接前后放置，不加任何分隔符： orderId={{date(YYYYMMdd)}}{{int(0000-9999)}}

图：Yakit HTTP请求编辑器中的Fuzztag语法示例

执行与结果解析

当测试启动后，Web Fuzzer 引擎的执行逻辑如下：

  1. {{date(YYYYMMdd)}} 首先被解析，生成一个固定的字符串，例如 20250622。

  2. 接着，{{int(0-9999)}} 生成器开始迭代，依次产出 0, 1, 2, ...

  3. 引擎将第一步的静态日期前缀与第二步的每一个动态数字进行字符串拼接，形成最终的载荷，如 20250622、202506220001、202506220002 等，并构建完整的 HTTP 请求发送出去。

图：Yakit Web Fuzzer界面展示Fuzztag生成器串联应用

关键点说明：Payloads** 列的展示机制**

请注意，Web Fuzzer 的结果列表中 Payloads 列的设计是为了便于调试和追溯。当一个参数由多个 Fuzztag 生成器组合而成时，该列会使用逗号 , 将每个生成器的当次输出值分隔开，例如 20250606,0001。这清晰地展示了最终载荷的构成来源。然而，在实际发送的 HTTP 请求中，这些值是被无缝拼接在一起的（即 orderId=202506220001），并不包含逗号。

这个案例深刻地揭示了 Fuzztag 设计中的一个核心原则：模块化与组合性。每一个 Fuzztag 函数（如 int, date, randomstr 等）都可以被视为一个独立的“功能积木”。通过将这些基础积木以不同的方式组合、嵌套，测试人员能够构建出几乎无限种类的复杂数据模式，从而精确地模拟各种应用场景的业务逻辑，这是实现深度、有效自动化安全测试的基石。

至此，我们已经掌握了 Web Fuzzer 在“输入端”的强大能力——即如何构造从简单到复杂的各类测试载荷，并以工业级的速度和规模将其发送出去。然而，高效的模糊测试流程远未结束。当执行一个 {{int(0-9999)}} 的遍历任务时，我们生成了 10,000 个请求，同时也收获了 10,000 个响应。这引出了自动化测试流程中同等重要的另一半挑战：信息处理与结果甄别。在海量的返回数据中，如何自动、精准地识别出那些真正有价值的响应——无论是代表成功的 Status: 200 OK，还是包含了特定错误信息的 Status: 500 Internal Server Error？手动检查数以万计的结果不仅效率低下，而且极易遗漏关键线索。