Burp Intruder Payload机制详解：从基础类型到实战应用

1. 认识 Intruder 的 Payload 机制：先从整体拆解思路

Burp Intruder 是 Burp Suite 里被用得最多的自动化测试模块之一，凡是涉及"把一堆数据反复往某个位置塞"的场景——登录口令爆破、接口参数枚举、目录遍历、SQL 注入/XSS 的 fuzz——基本都是它在干活。而 Intruder 真正拉开效率差距的核心，就是 Payload。

很多人用 Intruder 只会选一个 Simple list，然后加载字典就开跑。我最早也这样，直到我接手一个站点测试，目标在登录接口做了账号锁定策略，单纯用固定字典跑几次就全被 ban 了，后来靠 Intruder 的 Payload Processing 配合多个 Payload 类型做组合混淆，才把测试继续推下去。从那时候起我开始认真把每种 Payload 类型的原理、适用场景、坑全部过了一遍。

先说理解 Payload 的基础框架。Intruder 的工作流程可以拆成四块：

• Target：目标主机和端口
• Positions：标记攻击位置，用 § 符号把请求中要替换的位置框出来
• Payloads：定义用什么数据去替换标记位置
• Options：控制攻击方式（线程、重定向、匹配规则等）

整个机制的核心是：Intruder 根据你在 Positions 中设置的攻击位置数量，以及选择的 Attack Type（Sniper、Battering ram、Pitchfork、Cluster bomb），决定 payload 如何被填充到不同位置。而 Payload 类型则决定"这些数据是从哪来的、长什么样、在进请求前还要不要被加工"。

提示：如果你连这些基础概念都不清楚，建议先跑一次最简单的 Sniper 攻击，把请求和响应面板的对应关系看明白，再回来读 Payload 类型。否则后面的组合玩法你很难直观理解到底哪里被替换了。

这篇文章主要以 Burp Suite Community / Professional 2023 之后的版本为参考，新版本的 Intruder 界面重做过（Professional 里有新的 Intruder 面板），但 Payload 类型这套东西基本没变，你按名字对着找就行。

2. 基础 Payload 类型逐个拆解：别只会用 Simple list

2.1 Simple list：最常用的字典模式

Simple list 就是最简单直接的"列表数据源"。你可以手动输入一个词条，也可以从文件加载一个字典。它的逻辑就是按顺序取出列表里的每一项，替换掉标记位置。

这个类型的核心价值在于你给它什么它就发什么，不做任何加工。所以它适合所有"输入值就是最终值"的场景，比如：

• 用户名/密码字典枚举
• 路径字典扫描
• 参数名枚举
• 备份文件名字典（xx.php.bak、xx.php~ 这类）

使用上有两个值得注意的点。第一，手动添加大量数据时效率很低，建议直接用文件加载；文件里的数据会按行读取，每行作为一个 payload。第二，列表支持直接粘贴多个值，粘贴时默认以换行分隔，这个有时候容易误操作。

我习惯的做法是：先手工放几个关键值验证请求格式和响应差异，确认无误后再加载完整字典。比如测登录接口，先放 admin、test、user 三个值，看服务器对不存在的账号返回什么状态码/响应长度，再扩大字典。

2.2 Runtime file：大字典不占内存的加载方式

Runtime file 和 Simple list 的差别在于数据的读取方式。Simple list 是把整个字典一次性加载进内存，而 Runtime file 是每次迭代从文件里"按行读"，用完即弃。

这个类型的核心优势体现在超大字典场景。我有一次做子域名字典枚举，字典文件有 3GB，如果直接加载到 Simple list，Burp 有概率卡死或者消耗大量内存。而用 Runtime file 可以把这个负担转移到磁盘 I/O 上，Burp 本身保持流畅。

用法很简单：在 Payload type 下拉框里选 Runtime file，指定文件路径，然后 Burp 攻击过程中会实时从这个文件读取下一行。这个模式有一个特性：它不像 Simple list 那样可以预览所有 payload，你在攻击开始时看不到完整列表。

实操中还有一个小技巧：Runtime file 读取过程中如果你手动暂停攻击，再继续，它是从暂停的地方继续读，而不是从头开始。所以如果你目标的目标是"断点续跑"，这个类型反而比 Simple list 更适合。

2.3 Custom iterator：多位置组合的"穷举器"

Custom iterator 是我非常喜欢的一个类型，它本质上是"多个位置数据的笛卡尔积生成器"。比如你有三个位置，每个位置各有一组字符/字符串，它可以生成"位置 1 的所有值 × 位置 2 的所有值 × 位置 3 的所有值"这个组合集。

举个例子：你想枚举一个形如 user### 的账号名，其中 ### 是三个数字位，每位是 0-9。你可以设置三个 position，每个 position 的列表都是 0,1,2,...,9，生成结果就是 000-999 共 1000 个组合。

这个类型的实际应用非常广，但很多人没有意识到它和 Cluster bomb 攻击模式的配合差异：

• Cluster bomb 是在"多个§标记位置"之间做组合，一个位置的 payload 每次迭代取下一个
• Custom iterator 是在"payload 生成阶段"就把组合数据生成出来，最终只作为一个"大的列表"提供给单个标记位置

所以如果你的请求中只有一个位置需要生成组合数据，用 Custom iterator 会更清晰；如果有多个位置需要分别控制不同组合方式，用 Cluster bomb 更合适。

在 Custom iterator 的配置界面里，你可以添加多个 position 列表，并且修改每个列表的"输出顺序"。默认是 position 1 变化最快，类似循环嵌套里最内层循环。如果你要调整输出顺序，点上下箭头改变 position 的顺序即可，这里不要搞混，很多人在这里把顺序调了后，生成的组合完全不符合预期。

注意：Custom iterator 生成 payload 时会一次性把所有组合预计算出来。如果你设置 10 个位置，每个位置 36 个字符，你会得到 36^10 个组合，大概率直接把内存打爆。我在实操中建议组合数控制在百万级别以下，再大就改用脚本生成字典文件，然后配合 Runtime file 来跑。

2.4 Character substitution：同一份数据的花式变体

Character substitution 的作用是：基于你输入的原始字符串，自动按照你指定的字符映射表生成变体。例如原始字符串是 admin，你设置字符映射 a -> @、i -> 1，它会生成 @dmin、`a