企业官网建设流程全解析

说实话，我刚开始接触Burp Suite那会儿，最让我困惑的就是这个Intruder模块。界面上左一个Positions右一个Payloads，术语又密，没人带着捋一遍真的容易绕晕。但等你真正吃透它，会发现这几乎是日常测试里效率提升最大的一环——原来需要反复改包重发的活，它能一口气把几百种组合全打出去。这篇文章我打算从头到尾把入侵者模块掰开揉碎讲清楚，包括它的四种攻击类型怎么选、Payload位置怎么标记、拿到结果后怎么快速锁定有效数据，还有我实际测试中踩过的坑。不管你用的是社区版还是专业版，只要想把Burp Suite的自动化能力用起来，这篇应该都能对你有帮助。

1. Intruder到底是个什么东西：先明白它解决的痛点

先说个我早年干过的笨事。那时候接到一个授权测试任务，目标是一个管理后台的登录接口，我需要验证它是否存在账号枚举和弱口令问题。我当时干的事情特别原始：抓包拿到POST请求，复制到文本编辑器里，手动把用户名和密码字段替换一遍，粘回Burp Repeater，发一次，看响应，再换一组。测了大概十几组之后我整个人就烦了，眼睛盯着那一堆HTTP状态码和响应长度，生怕漏掉任何一条不一样的返回。

后来我才意识到，这种活根本不该用手工做。Intruder说白了就是一个"自动化请求生成器"：它把你拦截到的一个HTTP请求当作模板，你在模板里标记出若干个位置（Payload Positions），然后给它准备一份或多份字典（Payload），它就会按你指定的组合方式，自动生成成千上万条请求，替你把它们全部发出去，并把响应结果整理成表格方便你对比。

这个思路听起来简单，但它解决的是安全测试里最普遍的一类需求——枚举和爆破场景。举例来说，你要测一个网站是否存在目录遍历，手工去试admin、backup、test、upload这些路径，试一百个得操作一百次；放到Intruder里，把路径部分标记成变量，加载一份内容为一百条字典的文件，几秒内全部跑完。你要验证一个接口是否存在ID越权，把请求里的订单号标记为变量，生成1到10000的整数序列，跑完以后按响应长度排序，越权数据立刻就现形了。登录接口的撞库、优惠券码的枚举、验证码的绕过、参数值的Fuzz测试，但凡涉及"同一个请求模板、大量不同的值"的，Intruder都能帮你自动完成。

还有一个容易被忽略的价值：它逼迫你把测试过程结构化。手工测试的时候人容易随手乱点，测到哪算哪；用Intruder你得先想清楚——哪个参数是变量，字典里放什么值，用哪种攻击类型，期望从响应里看到什么特征。这个过程本身就是一次完整的测试设计，做完了你对目标接口的理解其实比随便点点要深得多。

顺带提一个版本选择上的问题。网络上一搜全是"Burp Suite Professional破解版"，说句实在话，我不推荐大家去装来路不明的破解包。一来安全测试工具本身对可信度要求极高，你装上的是别人编译好的二进制，里面塞了什么后门你根本不知道；二来社区版其实足够覆盖大部分Intruder的学习场景，真正被限制的只有极速模式、资源池的部分高级选项和保存项目功能，对个人学习和基础测试来说影响不大。就算真想用专业版，官方也提供了试用期，花点时间注册一下就行。

2. 动手前先配置这三样：目标、位置和负载

真要上手配置一个Intruder攻击，核心流程就三步：告诉它"打谁"、"打哪里"、"用什么打"。对应到界面上就是Target、Positions和Payloads三个标签页。我下面把每一步的逻辑拆开讲，顺便说一下为什么这么设计。

2.1 Target标签：目标信息从哪来

Target标签页里的主机地址、端口号和HTTPS协议都是自动填好的，来源就是你发送到Intruder时选中的那个原始请求。这块基本不用手工改，但有一点值得留意：如果你勾选了"Use HTTP"那一栏，Burp会尝试自动升级到HTTPS，某些情况下反而会引发问题，我一般保持默认即可。

这里真正容易出岔子的反而是它的上游操作。你的请求必须是从Burp Suite的HTTP History、Repeater或者Proxy拦截窗口里，右键选择"Send to Intruder"（默认快捷键是Ctrl+I）发送过去的。如果你像某些教程里那样，手工在Intruder的编辑器里粘贴了一段完整的HTTP报文，那也行，但格式稍有差错——比如末尾缺了空行、请求头大小写问题、Body和Header之间没有空行——Burp就无法正确解析，攻击自然是失败的。

2.2 Positions标签：搞清楚你的变量在哪里

Positions是整个模块里最需要耐心理解的部分。Burp把请求报文展示在一个文本编辑器里，你可以用鼠标选中某段内容，点击"Add §"按钮，给它加上一对"§"标记。一对§§之间的内容，就是一个Payload Position。攻击时，Intruder会把你准备的数据替换到这个位置上。

实际操作中有几个容易搞混的点。§符号和$完全不是一回事，§是Burp自己用来标记变量位置的，它不会被发出去；而如果你要在请求正文里发送美元符号，那是正常内容，别动它。页面上方有四个控制按钮：Add §是给选中文本加标记，Clear §是清除当前包里所有标记，Auto §是让Burp自动识别常见的参数位置，Refresh §则是重新解析包并更新标记。Auto功能在某些情况下意外地好用，比如请求参数多了你想全部枚举一遍，它能把所有GET参数或POST表单字段都标上，省得手动一个个加。

但这里我必须讲一个很多人踩过的坑——默认情况下，当你把请求发送到Intruder时，Burp只会自动标记一个位置，也就是它猜测的最可能的单个参数。如果你想同时枚举两个参数，比如登录接口的用户名和密码，那必须要手动把两个字段都加上标记。很多人没注意，直接在Payloads里加载了一个双字段组合字典，结果跑完发现请求里只有密码在变，用户名始终是固定的，测试结果完全无效。这个问题的本质是没搞懂"多个位置"和"多个字典"之间的关系，下面讲攻击类型时会再深入说。

另一类常见的错误是把Cookie或者User-Agent也标记成变量后，忘记给它们设置Payload。一旦某个位置没有对应的Payload，Intruder在发送请求时会把该位置替换为空字符串。很多接口对空参数是会直接报错的，于是你的一整轮攻击全都白费。我现在的习惯是，配置完Positions以后，切到Payloads标签页，逐一检查每个Payload set有没有配上实际内容。

2.3 Payloads标签：字典的类型、加载和预览

Payloads就是你准备好的"炮弹"，可以是一份文本文件、一个内置的生成器、甚至是一堆规则的组合产物。这块的UI虽然看起来繁琐，但核心概念就四个：Payload set（字典集）、Payload type（字典类型）、Payload processing（字典处理规则）、Payload encoding（是否做URL编码）。

先讲Payload set。Intruder支持最多8个Payload set，每个set对应Positions里的一组标记位置。比如你标了三个变量，那这里就会有三组Payload set。有多少个set需要配置、每个set加载什么内容，完全取决于你在Positions里标了几个位置以及你选的攻击类型。别看到"8个"就以为每次都要配满，多数场景一两个set就够了。

Payload type则是字典的来源方式。常用的有这么几种：

• Simple list（简单列表）：最常用，直接在文本框里手动输入，或者从文件加载。做目录扫描、接口枚举、用户名字典都用它。
• Runtime file（运行时文件）：从文件按需读取。适合超大字典，Burp不会一次性把整个文件载入内存，跑起来更省资源。
• Numbers（数字序列）：生成连续整数，从多少到多少，还有步长。测ID越权、订单号枚举、验证码顺序枚举的时候秒出结果。
• Brute forcer（暴力破解）：按指定字符集和长度生成所有排列组合。适合纯密码暴破，但组合数量膨胀极快，位数稍微一多就天文数字，慎用。
• Character blocks（字符块）：生成指定长度的连续字符片段，多用于协议Fuzz测试。
• Dates（日期）：按格式生成日期序列，比如生日字典、有效期枚举。

选完类型以后，下方还有Payload processing区域，可以添加多条处理规则，对生成的payload做二次加工，比如加上固定前缀、转成Base64、做URL编码、取前N位等。这块功能强大但不少人没用过，我后面单独用一节来讲。

最后是Payload encoding，默认会勾选URL编码，让payload安全地放进请求参数里。除非你明确知道自己要发送原始字节（比如某些二进制协议测试），否则保持默认就行。

3. 四种攻击类型怎么选：从Sniper到Cluster bomb的选型逻辑

攻击类型（Attack Type）是整个Intruder配置的灵魂。它决定了Payload和Payload Position之间的匹配关系。很多人配置半天还是一脸懵，关键就是没把这一层的逻辑想明白。我用大白话来逐个拆解。

3.1 Sniper（狙击手）：一次只打一个点

Sniper是我平时用得最多的类型，也是理解其他类型的基础。它的规则是：无论你标记了多少个Payload位置，它每一轮请求只替换其中一个位置，其他位置保持原始值不变。如果一个请求里有多个标记位置，它会先把第一个位置的所有payload轮一遍，再把第二个位置的所有payload轮一遍，以此类推。

比如说你标记了登录请求里的用户名和密码两个字段，字典里有100个用户和100个密码。用Sniper跑，前100个请求是用户名从第1个到第100个变化、密码固定为原始值；后100个请求是用户名固定为原始值、密码从第1个到第100个变化。总共发出200个请求，而不是1万个。

所以Sniper适合什么？适合"逐个排除变量"的测试。比如你想分别找用户名和密码各自的枚举特征，或者要遍历ID、扫描目录，总之场景里只有一个真正的变量、其他参数保持固定时，Sniper就是最稳的选择。它在Intruder的所有攻击类型里对目标产生的流量也最小，相对不容易触发WAF警报。

但Sniper有个天然局限：它在多位置场景下不会把不同位置的payload做组合。需要组合多个变量的组合时必须换攻击类型，这是很多新手的第一个理解障碍。

3.2 Battering Ram（攻城锤）：一个炮弹打穿所有点

Battering Ram的思路很直接：把同一个payload同时替换到所有标记位置上。你准备一份字典，里面有100个值，标记了3个位置，那么发出的就是100个请求，每个请求里3个位置的值都是一样的。

这种场景什么时候用？举个实际例子：某个接口的请求里，token既出现在Header里又出现在Body参数里，服务端可能会校验两处是否一致。你想要验证的是"当token为某个值时整个请求是否有效"，而不需要两个位置的token取不同值，这时候Battering Ram就比Sniper高效得多——它只需要一份字典，就能保证同一轮所有位置同步更新。

再比如你要测一个应用里的多处签名参数，把请求里的sign和key都标记为变量，用Battering Ram灌入同一组签名候选值，跑完看哪一轮通过了校验。这类"不同位置需要同值同步"的场景就是它的主场。

3.3 Pitchfork（干草叉）：像拉链一样配对

Pitchfork模拟的是"按索引配对"的逻辑：第1个位置用第1个set的第1个值，第2个位置用第2个set的第1个值；第2轮用各自set的第2个值，依次类推。最终请求数等于最长的那个set的长度，较短set用完后就保持最后一个值不变。

拿登录爆破举例，你有一份用户名字典和一份密码字典，且这两份字典是按行对应的——第1个用户对应第1个密码，第2个用户对应第2个密码。这个场景你说它真实吗？真实，但更多出现在撞库时从其他途径泄露的账号密码组合里，而不是普通的爆破。普通爆破往往需要的是"每个用户名都试遍所有密码"，那是笛卡尔积，要找Cluster bomb。

Pitchfork的典型应用反而是验证码绕过的测试。假设一个短信登录接口需要三个参数：手机号、验证码、时间戳。你要验证的是"如果验证码固定为一个失效的旧验证码，是否能通过校验"，那可以把手机号放在set1、验证码放在set2，然后按行配对，让每行都是"一个新的手机号+同一个旧验证码"。跑完如果发现了能登录成功的响应，就说明验证码失效问题存在。

这里必须提醒一句：Pitchfork要求你心里清清楚楚set1和set2的行是"有意配对"的，而不是"恰好长度相同就顺手配了"。如果两个set的行之间没有逻辑对应关系，配对出来的请求可能完全没有意义，测试结果也不能说明问题。

3.4 Cluster bomb（集束炸弹）：穷举一切可能

Cluster bomb是唯一真正做笛卡尔积的类型。有N个位置、每个位置各自有一份字典，它会把所有字典的值做全组合。比如用户名字典100条、密码字典100条，两个绘图对应的组合数就是100×100=10000条请求。

这正是登录爆破最常用的攻击类型。每一条请求都是"一个用户名+一个密码"的独立组合，覆盖了所有可能性。只要你的字典质量靠谱、目标接口没有防爆破机制，最终一定能跑出正确的那一组。

但集束炸弹的代价也显而易见：请求量指数级膨胀。三个位置、每份字典50条，那就是125000条请求，哪怕每个请求只要0.3秒，也得跑十个小时以上。实际操作中我一般会把最耗时的字典控制在合理数量，或者先用少量样本做一次探测，确认目标接口的响应规律和限流机制以后，再上全量字典跑。不要一上来就砸一个百万级字典，人和目标服务器都吃不消。

3.5 四种攻击类型的快速对照

为了方便你后面配置时快速决策，我把四种类型的核心特征整理成了一张表：

这个表是我每次配置Intruder之前都要在心里过一遍的。决策顺序其实就三步：先数清楚你标了几个位置，再看你有几份字典，最后想清楚你希望它们怎么组合。想清楚了，选型就很自然。

4. 实战场景操练：三个案例把配置串起来

光讲理论不实操，过几天肯定忘。我用三个高频场景把前面的知识串起来，每个场景都给出完整配置过程和结果判断方法，你回去照着配一遍就能建立肌肉记忆。

4.1 场景一：登录接口撞库测试（Cluster bomb）

假设目标是一个web登录接口，请求格式是POST /api/login，Body是username=admin&password=123456。要测试弱口令，我的配置流程是这样的：

1. 在Burp里确保已拦截到这个登录请求，右键选择"Send to Intruder"。
2. 切到Positions标签，攻击类型选Cluster bomb。清空所有已有标记，然后手动选中admin，点击Add §；再选中123456，点击Add §。此时请求变成username=§admin§&password=§123456§。
3. 切到Payloads标签，会看到Payload set 1和Payload set 2。set 1选Simple list，加载用户名字典；set 2同样选Simple list，加载密码字典。注意顺序别反了——set 1对应的是第一个标记位置（username），set 2对应第二个标记位置（password）。
4. 在Options标签里的Grep-Match部分，添加一个成功登录后响应中才有的特征字符串，比如"欢迎"、"dashboard"或重定向的Location值。这一步很关键，后面筛选结果时全靠它。
5. 点右上角Start attack，等结果出来。

这里说一句，Grep-Match的判断字符串一定要在Repeater里先手工试几次，确认那个特征在成功响应里必然存在、在失败响应里绝对不会出现，否则筛选结果时会错漏百出。

4.2 场景二：短信验证码绕过测试（Pitchfork）

这个是我在实际项目中遇到过的场景。某平台的找回密码接口，请求参数是mobile=13800138000&code=123456&timestamp=1700000000。业务逻辑里验证码有有效期限制，我想验证一下"用旧的失效验证码是否还能通过校验"。

思路是这样的：我需要构造若干条请求，每条请求里手机号不同，而验证码保持为一个已经失效但历史上真实生成过的验证码。手机号和验证码的配对关系是固定的，用Cluster bomb会生成大量没意义的组合，用Pitchfork正好。

配置步骤：

1. 标记位置：把mobile的值和code的值分别加上§标记。
2. 攻击类型选Pitchfork。
3. Payload set 1加载一份手机号列表，set 2加载只含一个值的验证码列表（那个历史验证码）。
4. 在Options里加一个Grep-Match特征：接口返回"验证通过"或跳转到重置密码页面时的标识。

跑完以后，如果存在"验证码失效但服务端未作废"的漏洞，你会在结果里看到若干条响应命中了Grep-Match特征。这个案例的要点就是set 2虽然有100行，但所有行都是同一个值；配对产生的100条请求恰好是"100个手机号各带同一个验证码"，逻辑完全成立。

4.3 场景三：订单ID越权读取（Sniper）

再举一个偏数据安全的场景。一个订单详情接口，路径是/api/order/10086，我要验证是否存在越权——把订单号改成别人的订单号，响应会不会返回别人的订单信息。

配置更简单：

1. 标记10086这个订单ID。
2. 攻击类型选Sniper。
3. Payload type选Numbers，设置从10001到20000，步长1。
4. 在Options里加一个Grep-Extract规则，从响应中提取"order_id"字段的值。这样每条结果后面都会自动列出响应里实际的订单号，不用手工一条条翻看。
5. Start attack跑一遍，然后在结果里筛选order_id和请求中的数字不一致的记录。

这个案例特别适合用来帮你理解Sniper的定位：只有一个位置、只有一个变量，其他条件全部保持不变，就是要逐个遍历。跑完以后按响应长度排序，能一眼看到哪些订单返回的响应明显不同——那些往往就是越权成功的证据。

5. 跑题一下：Payload处理规则，让你的字典更有针对性

很多人配置Intruder时，只知道往Simple list里塞字典，完全不知道下面还有一个Payload processing区。这个区在你面对需要加工的场景时价值巨大，我把常用规则挑几个说说。

Payload processing可以理解成一条流水线：原始payload生成后，按照你添加的处理规则，从上到下依次加工，加工完的最终值才被放进请求里。规则类型有decoded（URL解码）、encode（URL编码）、add prefix/suffix（加前缀后缀）、match/replace（正则替换）、substring（截取）、case modification（大小写变换）等十几个。

举个真实场景。某接口登录时需要把密码先做MD5，再转成小写，然后作为passwd参数发送。你手头有一份明文密码字典，如果直接把字典塞进去跑，服务端校验的肯定全是错的。这时只要在Payload processing里加两条规则：先选Hash，算法选MD5；再加一条To lowercase。Burp会先对字典里的每个明文密码做MD5，再转小写，然后把结果放进请求里发出去，整个过程完全自动化。这是暴力破解里极高频的用法。

再举一个参数签名的场景。有个API要求请求参数必须带一个sign字段，规则是"时间戳+密钥拼接后做SHA256"。你手工去算每个payload对应的签名显然不现实，但可以在Payload processing里添加规则：先Add prefix（拼上前缀），再Hash（SHA256），最后Add suffix或者做URL编码，一条流水线就解决了。我见过很多人在这种场景下宁可去写脚本，也不肯用Intruder自带的处理规则，其实没必要，内置规则能覆盖绝大多数常规加密和编码需求。

还有一类规则是条件式payload（Conditional payload）。它能根据上一次请求的响应内容，从响应中提取指定子串，作为下一步请求的payload。利用这个可以实现递归grep——第一次请求提取出一个token，第二次请求携带这个token继续请求，第三次再提取再携带。这在多步交互类的fuzz测试、需要动态token的接口测试里非常实用。虽然配置起来比普通字典稍复杂，但它的核心逻辑仍然是"把提取结果喂给下一个请求"，调试的时候记得在Options里打开响应日志，逐轮观察提取是否正确。

6. 结果分析：几千条响应里怎么锁定"罪魁祸首"

Intruder跑完以后，结果窗口里往往躺着几千上万条记录。很多人这时候就懵了，一条条点开看，效率极低。其实Intruder内置的分析工具足够强大，关键看你有没有用对。

结果表格的列默认有请求号、攻击类型、Payload位置参数、状态码、响应长度、响应时间等。排在最前面的筛选技巧就是按状态码和响应长度排序。大多数情况下，正常响应的长度集中在一个区间内，一旦某个响应长度明显与众不同，往往代表它的内容不同寻常——要么是查询到了数据，要么是错误提示不同，也可能是跳转到了不同的页面。这个"不同"正是你测试中要找的线索。

举个例子：你测一个目录枚举，大部分目录返回404，长度都是732字节；突然有一个目录返回200，长度是4389字节，那你都不用看内容，基本可以断定这个目录是存在的、里面有内容。长度过滤是在大量结果里快速定位异常的可靠手段。

Grep-Match在前面提过几次，它是更精确的筛选工具。你在Options里配置好特征字符串以后，结果表格里会出现一个专门的勾选列，命中的记录会打勾。与其手动翻看几百个响应找"登录成功"字样，不如让它自动勾选出来。另一个工是Grep-Extract，可以定义从响应中提取某个正则匹配的子串，结果里会多出一列，直接展示提取值。比如你测验证码枚举，把响应里的"验证码错误"、"验证码正确"这类提示提取出来，整个结果一目了然。

还有两个细节我建议大家养成习惯。第一，跑完以后不要只盯着状态码200的结果，有些接口对未授权访问会返回200但Body里是空的，有些则会返回302跳转到登录页。状态码只是参考，结合长度和特征筛选才是可靠的判断维度。第二，在结果窗口里选中某条记录按Ctrl+R，可以直接把这条请求发送到Repeater里手工复现和验证，我每次发现可疑结果都会挨个复现一遍，防止误报。

7. 资源池与速度控制：别把自己反锁在目标门外

Intruder默认的发送速度其实相当克制，但很多人一看到"线程数"就兴奋，直接把Number of threads拉到100，结果跑了没几分钟，自己的IP被目标站点的WAF封了，后面什么都测不了。这属于典型的操之过急。我自己对这个问题的态度是分层级的：

• 对公网生产环境，线程数建议不超过10，最好从5开始，观察目标的响应速度和自身网络情况再慢慢加。
• 对本地搭建的靶场或测试环境，可以放开一些，比如拉到20到30，但也没有必要一次性拉满，因为Intruder的瓶颈往往不在线程，而在于目标网站在限流和带宽。
• 如果你的测试需要长时间跑，建议在Resource Pool里设置延迟（Delay between requests）。比如设置间隔500毫秒，请求速率稳定下来也就每秒两个，对绝大多数站点来说是友好的。

Resource Pool这个功能平时很容易被忽略，它在Intruder攻击窗口右上角的配置里。点开以后可以创建自定义资源池，设定最大并发连接数和请求间隔。合理配置资源池的作用不只是保护目标，也是保护你自己的测试稳定性——并发太高导致大量超时和连接重置，结果数据一塌糊涂，反而浪费时间。

另外提一点运行控制的经验：长期运行的攻击最好勾选"Run in background"，这样你可以同时用Repeater或新开其他标签去干别的事。攻击过程中如果发现payload加载错了，不需要等全部跑完——点Abort吗？不一定，Intruder支持暂停（Pause），暂停后可以调整部分设置再继续。不过我亲测下来，如果是Payload内容本身配错了，直接停止、修正配置、重跑，比在暂停状态下费劲修改更省时间。

8. 那些年我在Intruder上踩过的坑，以及怎么绕开

讲到这里，基础配置和进阶用法都覆盖得差不多了。但我觉得还应该单独用一节把实操中高频出现的坑列出来，这些坑我几乎每次带新人或者看群友提问时都能碰到。

坑一：搞不清楚Payload set与标记位置的对应关系。
这个问题前面已经反复强调，但真的太多人栽在上面了。请记住一个铁律：Positions标签里的标记顺序，决定了Payloads标签里的set编号顺序。第一个标记对应set 1，第二个标记对应set 2，以此类推。你配置完以后先别急着Start，在Payloads标签页确认一下每个set挂的是哪份字典，再用少量数据做一轮试跑，抓一条实际发出去的请求看看里面的变量替换是否符合预期。

坑二：标记位置时连引号或分隔符一起标记了。
这个错误特别隐蔽。比如请求是username=admin&password=123456，正确做法是只标记admin和123456，但有人偷懒直接选中admin&password=123456整个加标。结果就是你发送的payload会覆盖掉参数分隔符&，导致请求格式错乱，服务端根本解析不了。无论什么时候，标记的范围都要精确到"变化的值本身"，别贪多。加完标以后，肉眼看一遍请求模板，确认§符号的位置在参数值两端、而不是包住了结构字符。

坑三：忘记Grep-Match配置，结果跑完了不知道哪条成功。
跑了几万条记录以后靠肉眼找特征，这真的是效率灾难。我见过有人在Intruder结果里逐条点开，纯手工找"success"，看到眼睛酸痛。从一开始就养成习惯：任何预期要反复发包的测试，先手工发一两次请求，确认成功与失败响应之间的差异字符串，然后在Options里配好Grep-Match。这会让你后续所有分析步骤轻松一个量级。

坑四：只用状态码判断成功，被假200迷惑。
Web应用的鉴权失败未必返回401或403，很多前端框架的路由处理逻辑会让未登录请求仍然返回200，但Body里是空的或者只是一段提示脚本。所以判定成功与否，永远要结合响应内容特征，再来谈状态码和长度。

坑五：网络环境差或者代理变动，导致Intruder请求全部超时。
这个问题比较偏环境。如果你发现Intruder跑起来大片连接超时，先查一下Burp的上级代理设置和目标站点连通性，别一上来就怪Intruder配置有问题。另外如果你用了某些系统代理工具，它的运行状态变化会直接影响Burp的请求转发，这种间歇性超时排查起来特别磨人，必要时直接把系统代理关掉再试。

坑六：正则表达式或Grep-Extract的提取规则写错。
Grep-Match支持正则表达式，比如你想匹配"验证码错误"或"验证码失效"，可以写验证码(错误|失效)。但对于不熟悉正则的人来说写出来的模式经常匹配不到任何内容，结果就是所有响应都不勾选，看起来一无所获。我的建议是：先在Repeater里复制一条实际响应内容，到支持正则的文本工具里验证一下你的pattern能不能命中，确保匹配规则本身是可靠的，然后再回到Intruder用。

说到底，Intruder这个模块的掌握程度，很大程度上决定了你的Burp Suite测试效率。它本身不复杂，但如果不理解它底层的"请求模板+变量位置+字典组合"这三层逻辑，就会出现配置混乱、结果看不懂、误报漏报各种问题。我分享的这些内容，基本覆盖了从入门到进阶的完整路径，你在实际测试中按照这个思路去配，很快就能建立起自己的节奏。最后再提醒一句：不管用来做什么测试，一定要确保是在授权环境下进行，这是安全测试的大前提。