1. 项目概述为什么Payloads设置是Intruder的灵魂如果你用过Burp Suite的Intruder模块肯定有过这样的经历目标明明存在漏洞但跑了几十万条Payload结果要么全是“302重定向”要么就是“200 OK但长度都一样”最后只能对着屏幕干瞪眼怀疑人生。问题出在哪十有八九是你的Payloads设置没到位。Intruder模块说白了就是一个自动化请求发送器它的威力完全取决于你“喂”给它什么“弹药”。Payloads设置就是为这台“加特林机枪”装填子弹、调整弹道、甚至给子弹涂上“隐身涂料”的过程。很多人把Intruder等同于“爆破工具”这其实大大低估了它。一个配置精良的Intruder攻击可以用于模糊测试、数据枚举、逻辑漏洞探测、竞态条件检测等十几种场景。而这一切的起点和核心就是Payloads面板。从最基础的字典列表到应对复杂WAF规则的编码处理再到利用外部脚本生成动态Payload每一步都藏着细节和坑。这篇文章我就结合自己这些年从“无脑跑字典”到“精准打击”的踩坑经验把Intruder Payloads的设置掰开揉碎了讲清楚。无论你是刚入门的新手还是想提升效率的老手这里面的技巧都能让你少走弯路。2. Intruder Payloads基础理解四种攻击类型与载荷位置在深入Payloads设置之前我们必须先统一“战场”的理解。Intruder支持四种攻击类型Attack Type它决定了你的“子弹”Payload如何被“发射”到目标请求的不同“弹着点”插入点上。选错类型后续所有精细的Payload配置都可能白费功夫。2.1 四种攻击类型详解与选用场景Sniper狙击手模式这是最常用也最容易被误解的模式。它只有一个Payload集合。工作方式是依次将Payload集合中的每个值轮流替换你标记的每一个插入点Position但一次只替换一个点其他插入点保持原始值。假设你标记了两个插入点username§admin§password§123456§Payload集是[‘admin’, ‘test’, ‘guest’]。那么Sniper会生成如下请求usernameadminpassword123456(替换第一个点)usernametestpassword123456usernameguestpassword123456usernameadminpasswordadmin(替换第二个点注意这里密码也变成了Payload值)usernameadminpasswordtestusernameadminpasswordguest注意很多新手以为Sniper是“一对一击破”但它其实是“逐个位置测试同一个Payload集”。它最适合测试单个参数是否存在注入、越权等漏洞比如测试一个ID参数id§1§的SQL注入。绝对不要用它来测试用户名密码这种需要组合爆破的场景否则就会出现上面例子中“用户名是admin密码也是admin”这种不合逻辑的测试用例。Battering ram攻城锤模式同样只有一个Payload集。它的行为是用同一个Payload值同时替换所有你标记的插入点。还是上面的例子Payload集是[‘admin’, ‘test’]那么生成的请求是usernameadminpasswordadminusernametestpasswordtest这个模式使用场景比较特殊适用于那些需要多个参数保持相同值的测试比如测试“修改邮箱”功能时new_email和confirm_new_email两个参数需要相同。Pitchfork草叉模式这是组合爆破的正确打开方式。它允许你为每一个插入点配置一个独立的Payload集。Intruder会从每个Payload集的相同索引位置取出值组合成一个请求。比如你为username标记点配置Payload集A[‘admin’, ‘root’]为password标记点配置Payload集B[‘123456’, ‘password’]。那么生成的请求是usernameadminpassword123456(取A[0]和B[0])usernamerootpasswordpassword(取A[1]和B[1])关键点Payload集长度不同时攻击会以最短的集合为准停止。所以务必确保你的用户名和密码字典长度匹配或者使用“Continue indefinitely”选项循环使用较短的列表。Cluster bomb集束炸弹模式这是最暴力、最彻底的枚举模式。它也为每个插入点配置独立的Payload集但会进行笛卡尔积运算即每个Payload集的值都会与其他集的所有值进行组合。使用上面的例子usernameadminpassword123456usernameadminpasswordpasswordusernamerootpassword123456usernamerootpasswordpassword这会产生len(A) * len(B)个请求。对于用户名密码爆破这是标准选择但务必小心字典大小两个5000条的字典会产生2500万次请求极易把自己或目标“打挂”。2.2 Payload Positions精准标记你的攻击点理解了攻击类型标记插入点就是下一步关键。在Burp的Proxy或Repeater中右键发送到Intruder后切换到Positions标签页。Burp通常会帮你自动标记一些它认为的可变参数如Cookie、POST参数但永远不要完全相信自动标记。手动标记技巧清晰视图点击 “Clear §” 按钮清空所有自动标记。精确选择用鼠标精确选中你想测试的值如参数值、Cookie值、Header头值甚至是JSON字符串中的某个key的value然后点击 “Add §”。复杂位置对于JSON或XML格式的请求体可以先切换到 “Hex” 视图找到对应值的十六进制位置进行精确标记避免引号或括号被错误包含。批量标记如果你有一串需要测试的ID如id1,2,3,4,5可以选中整段1,2,3,4,5点击 “Add §”然后在Payloads设置中使用 “Split” 处理器后面会讲将其按逗号分割。实操心得在标记JSON请求时一个常见的坑是标记了整个值字符串但忘了包含两端的双引号。例如{user:§admin§}是正确的而{user:§admin§}会导致Payload被注入到引号之外破坏JSON结构请求根本不会成功。务必在Raw视图下反复检查标记后的请求格式是否正确。3. Payloads字典配置从入门到高阶资源管理Payloads标签页是Intruder的“弹药库”。这里管理着所有要注入的原始数据。3.1 Payload类型深度解析Simple list简单列表最基础也是最强大的类型。就是一行一个Payload。你可以直接粘贴、从文件加载Load或手动添加Add。它的强大在于其“朴素”没有任何花哨的转换是一切复杂操作的基础。Runtime file运行时文件这是处理超大型字典的利器。不同于“Load”一次性将文件读入内存“Runtime file”是在攻击过程中按需从磁盘读取。这意味着你可以使用几个G甚至几十个G的字典文件而不会撑爆Burp的内存。代价是速度会慢一些因为存在磁盘I/O。适用于那些需要海量枚举如子域名、目录且对速度不敏感的场景。Custom iterator自定义迭代器用于生成具有固定模式或需要拼接的Payload。例如你想测试username01到username99这样的用户名。你可以定义多个“位置”每个位置设置一个字符集。位置1固定字符串username位置2数字列表0-9位置3数字列表0-9Intruder会生成username00,username01, ...,username99。这比手动准备一个100行的列表高效得多。它非常适合生成有规律的PIN码、特定格式的标识符等。Character substitution字符替换基于一个基础单词按照你定义的规则如将a替换为s替换为$生成变体。这是生成“Leet Speak”密码变体的好方法。例如基础词password规则a-, s-$会生成p$$word。你可以设置最小和最大替换次数来控制变体数量。Case modification大小写修改基于一个基础单词列表生成所有可能的大小写组合变体。例如admin会生成admin,Admin,ADMIN,aDmin等。注意一个长度为n的单词会产生2^n种组合。admin(5个字符)是32种而password(8个字符)是256种。轻易对一个长列表使用此选项会导致Payload数量爆炸。Numbers数字生成数字序列。你需要指定类型如整数、十进制、范围、步长和进制。一个高级技巧是结合“From”和“To”使用负数或者生成超长数字如19位身份证号来测试整数溢出。Dates日期生成日期序列。格式非常灵活你可以指定年、月、日的范围和格式如YYYY-MM-DD,DDMMYYYY。常用于测试生日、有效期、时间戳相关参数。Brute forcer暴力破解器在指定字符集和最小/最大长度范围内生成所有可能的排列组合。这是计算量最大的选项必须慎用。例如仅小写字母数字36个字符生成长度为3的所有组合就有 36^3 46,656 种。长度到6时就是36^6 20亿种。通常只用于测试非常短如3-4位的验证码、PIN码。Null payloads空载荷不替换任何内容而是直接发送原始请求插入点保持为空。这有什么用用于测试竞态条件Race Condition和速率限制。你可以设置线程数很高然后快速重复发送同一个请求观察服务端的并发处理是否会出现问题如重复充值、超额兑换。**Extension-generated扩展生成**和Copy other payload复制其他载荷用于高级联动比如从一个Payload的结果中提取信息作为另一个插入点的Payload实现“先查询后攻击”的链式操作。3.2 字典的获取、清洗与优化拥有一个好的字典攻击就成功了一半。但网上下载的“万能字典”往往体积庞大冗余极多针对性差。字典来源专用工具生成使用crunch,cupp,rsmangler等工具基于目标信息如公司名、产品名、泄露的用户名生成定制化字典。从目标本身提取这是最高效的方法。爬取目标网站的所有页面用cewl这类工具爬取所有独特单词生成专属字典。还可以从JS文件、HTML注释、错误信息中收集可能的路径、参数名。公开泄露库利用haveibeenpwned的API或下载rockyou.txt这类经典泄露密码集但一定要进行清洗和针对性筛选。规则变形使用Hashcat的--stdout模式或John the Ripper的--stdout和--rules功能对一个基础字典进行强大的规则变形生成海量高质量变体。字典清洗实战步骤去重sort -u wordlist.txt wordlist_unique.txt这是最基本操作。排序sort wordlist_unique.txt不仅为了整洁有时按长度或字母顺序排序的字典在测试时更有逻辑。按长度过滤很多系统有密码最小长度限制。使用awk length($0) 8 wordlist.txt wordlist_8plus.txt过滤出长度大于等于8的项。移除无效字符如果目标输入框明确限制某些字符可以用sed或文本编辑器批量移除包含这些字符的行。频率排序将最可能成功的项放在前面。例如将包含“admin”、“root”、“test”、“2023”、“2024”、“123”等常见弱口令的项提到字典顶部可以让你更快地发现“低垂的果实”。实操心得字典的“热加载”与“动态调整”。在攻击过程中如果发现某些模式如特定后缀、前缀的Payload返回了有趣的结果如响应长度不同不要停下来。立即将这些“疑似命中”的Payload提取出来保存为一个新的临时字典文件。然后在Intruder中为当前攻击添加一个新的Payload集类型选“Runtime file”指向这个新字典并调整攻击位置或类型进行第二轮聚焦测试。这种“观察-反馈-调整”的循环是高效手工测试的核心。4. Payload Processing编码、哈希与动态处理的魔法Payload Processing载荷处理链是Intruder Payloads设置的精髓所在也是区分新手和老鸟的关键。它允许你在Payload被放入请求之前对其进行一系列的处理。你可以添加多个处理器它们会按顺序执行。4.1 常见编码与哈希处理器URL编码这是最常用的处理器。当你的Payload包含特殊字符如空格、引号、尖括号、、时必须进行URL编码否则会破坏HTTP请求结构。例如测试SQL注入‘ or ‘1’’1如果不编码单引号会提前闭合字符串。编码后变成%27%20or%20%271%27%3D%271。规则只要Payload不是纯字母数字就先加上URL编码处理器。你可以选择对所有字符编码或只对非字母数字字符编码推荐后者。HTML编码用于测试XSS或当参数值最终会被放入HTML上下文时。例如将转换为lt;将转换为gt;。有时需要双层编码来绕过简单的过滤。Base64编码当遇到参数值被后端进行Base64解码时使用。例如你观察到请求中dataYWRtaW4对应admin那么你的Payload就需要先Base64编码。处理器里直接选“Base64-encode”即可。哈希函数MD5、SHA1、SHA256等。常用于测试“修改密码”功能当你发现前端发送的是密码的MD5值而非明文时。或者在一些API签名验证中需要对特定字符串进行哈希。添加前缀/后缀极其有用的功能。例如你发现所有的有效用户名后都有一个固定的公司后缀company.com那么你可以设置Payload为简单用户名列表然后添加一个后缀处理器值为company.com。这样你的字典就只需要维护核心用户名部分更加灵活。4.2 高级处理技巧条件化处理与链式组合处理器的强大之处在于可以链式组合和条件化执行。链式组合案例测试加密参数。 假设目标请求中有一个参数cipher你通过逆向JS发现它的生成方式是明文参数 - Base64编码 - 反转字符串 - 进行URL编码。 那么你的Payload处理链就应该设置为Base64-encode (对原始Payload进行编码)Reverse string (反转字符串)URL-encode all characters (进行URL编码) 这样当你输入Payloadadmin时Intruder会先将其编码为YWRtaW4然后反转为4aWtkYQ最后URL编码为%3D4aWtkYQ完美模拟了前端逻辑。条件化处理通过“匹配/不匹配”规则 处理器面板有一个 “Payload will be processed if...” 的下拉菜单。你可以设置规则让处理器只对符合特定条件的Payload生效。场景你的字典里既有纯数字PIN码如1234也有单词密码如password。你只想对单词密码进行“首字母大写”处理而不影响PIN码。设置添加一个“Capitalize first letter”处理器在条件规则里选择“Payload matches regex”输入正则表达式^[a-zA-Z]$。这样只有纯字母的Payload才会被首字母大写1234保持不变。实操心得处理器的顺序是生命线。一定要按照数据实际被处理的逻辑顺序来排列处理器。一个经典的错误是先URL编码再Base64编码。这会导致Base64编码器把%2B编码后的号这样的字符也当作原始数据的一部分进行编码完全扭曲了结果。正确的顺序应该是先进行业务逻辑的编码/哈希如Base64、MD5最后再进行传输所需的编码如URL编码。在不确定时用Repeater模块配合“Payload processing”的预览功能在Intruder的Payloads标签页有“Preview”子标签一步步调试观察每一步处理后的结果是否符合预期。5. Payload Encoding应对WAF与输入过滤的终极策略Payload Encoding在Options标签页的Request Headers和Request Engine附近有相关设置常常被人忽略但它是在网络层应对WAFWeb应用防火墙和输入过滤器的关键。它控制的是整个HTTP请求的传输编码与Payload Processing处理的数据内容编码是两回事。5.1 字符集与特殊字符转义URL编码全局在Intruder - Options - Request Headers部分有一个选项是 “URL-encode these characters”。你可以在这里添加除了标准保留字符之外你认为需要额外编码的字符。有些WAF会检测未编码的特殊字符如,强制进行全局URL编码有时能绕过简单的字符串匹配。Content-Type 与字符集在Options - Request Headers中确保Content-Type头与你的请求体格式匹配。如果是application/x-www-form-urlencoded那么参数通常需要URL编码。如果是application/json则参数值中的引号需要被转义\但通常不需要整个值进行URL编码。错误的Content-Type会导致后端解析失败。HTTP参数污染HPP编码这是一种高级技巧。你可以通过设置Payload使其在URL和Body中呈现不同的编码形式。例如在URL中发送%26的编码而在后端解析时它可能被解码为从而起到参数污染的作用。这需要在Payload Processing和请求构造上做精细配合。5.2 高级绕过技巧分块传输与畸形请求在Intruder - Options - Request Engine区域虽然不直接叫“Payload Encoding”但调整请求引擎的行为可以改变请求的“形态”从而绕过防御。分块传输编码Chunked Transfer Encoding这是一种HTTP协议特性允许将请求体分块发送。有些WAF会缓冲整个请求体进行检查而启用分块传输后WAF可能因为无法组装完整请求体而放行。在Burp中你可以在Repeater里手动添加Transfer-Encoding: chunked头然后按特定格式构造请求体。在Intruder中实现自动化需要借助Turbo Intruder扩展或自定义Python脚本因为原生Intruder对此支持不友好。利用空格、制表符和换行符在HTTP协议中头字段名和冒号之间可以有空格但这不符合严格规范。有些WAF的解析器严格而后端Web服务器如Apache、Nginx的解析器宽松。你可以在Intruder的Payload Processing中为请求头名称的Payload添加前缀空格例如将Cookie:变为Cookie :中间多个空格可能绕过基于正则匹配的WAF规则。更改请求方法有时对POST参数的过滤严格但对GET参数宽松或者反之。Intruder允许你修改请求方法。你可以尝试将POST /login改为GET /login?username§...§password§...§来测试。这需要在Positions标签页重新标记插入点。实操心得编码与绕过的“三层思维”。面对过滤我通常按这三个层次思考第一层内容编码Payload Processing。我的Payload数据本身是否需要变形如Base64、HTML实体、十六进制等。第二层传输编码Payload Encoding / 请求构造。我的请求在网络上传输的格式是否有问题是否需要分块、添加冗余头、改变参数位置如从Body移到URL第三层协议层请求引擎/工具。是否需要用更底层的工具如Turbo Intruder, 自定义Socket脚本来发送畸形协议数据包利用WAF与后端服务器协议解析的差异 绝大多数情况第一层和第二层的组合就足够了。第三层通常用于攻克非常严格的硬件WAF。6. 实战案例一个完整的用户名枚举与密码爆破流程让我们通过一个虚构但融合了多种真实场景的案例把上面的所有知识点串起来。目标是一个登录接口POST /api/v1/login请求体为JSON{username:user,password:pass,captcha:1234}。我们怀疑存在用户名枚举和弱密码漏洞。第1步侦察与标记Positions发送一个正常登录请求到Intruder。在Positions标签页点击 “Clear §”。我们计划先进行用户名枚举使用Sniper模式所以只标记username的值{username:§user§,password:pass,captcha:1234}。注意引号的位置。攻击类型选择Sniper。第2步准备用户名字典Payloads切换到Payloads标签页Payload类型选择Simple list。我们从一个基础字典开始如常见用户名admin, root, test, guest, administrator。考虑到目标可能使用邮箱登录我们添加一个Payload Processing添加处理器Add suffix值为targetcompany.com。这样我们的实际Payload会变成admintargetcompany.com,roottargetcompany.com...为了绕过可能的WAF关键字过滤再添加一个处理器URL-encode all characters(确保特殊字符如被编码)。顺序很重要先加后缀再URL编码。第3步配置识别与过滤Options - Grep Match为了从大量“200 OK”中找出成功的枚举我们去Options - Grep - Match。清除默认标记。在第一次请求使用无效用户名后点击 “Fetch response”。在响应中寻找用户名无效时的特征字符串例如“error”: “user not found”。选中它点击 “Add”。这样所有包含此字符串的响应都会被标记而不包含的可能表示用户名存在就会凸显出来。第4步执行与分析开始攻击。在结果中按“状态码”或“长度”排序寻找那些没有被我们标记的Grep字符串的响应。假设我们发现admintargetcompany.com的响应不包含“user not found”且响应长度与其他明显不同。这很可能是一个存在的用户名。第5步进阶密码爆破Pitchfork/Cluster bomb回到Positions现在我们知道用户名是admintargetcompany.com。我们调整攻击点为密码爆破。清空标记重新标记{username:admintargetcompany.com,password:§pass§,captcha:1234}。注意用户名部分固定为我们枚举到的有效用户。攻击类型改为Cluster bomb因为我们可能还要同时测试验证码但这里先假设验证码不变或已绕过。在Payloads标签页我们需要为每一个插入点这里只有密码一个点设置Payload集。Payload set: 1, Payload type:Simple list。加载一个弱密码字典如123456, password, admin123, targetcompany2024。添加Payload Processing考虑到密码可能被前端MD5处理我们先不加。先跑明文。如果失败再添加一个MD5 hasher处理器试试。由于验证码可能是个干扰项我们可以尝试将其值设为空或一个固定值如果接口允许或者也将其作为一个Payload点使用Null payloads类型并配合Pitchfork模式用一个很小的验证码字典如0000, 1111进行组合测试但这会极大增加请求量。第6步应对动态Token如果请求中还有一个CSRF Token如“csrf_token”:“a1b2c3d4”它每次登录都会变直接爆破会失败。方案A先获取再使用。用Burp的Macros宏和Session Handling Rules会话处理规则功能。配置一个宏在每次Intruder发送请求前先执行一次获取Token的请求如GET /login页面并从响应中提取新的Token更新到Intruder的请求模板中。这需要在Burp的Project options - Sessions中配置。方案B将Token也作为Payload点。使用Pitchfork模式为Token设置一个Payload集这个集的内容来自一个Extension-generated类型或者使用Copy from previous response的处理器链。但这比方案A更复杂。 对于新手方案A配置会话宏是更可靠的选择。这虽然超出了纯Payloads设置的范围但却是实战中必须掌握的关联技能。实操心得速度与优雅的平衡。在Intruder的Options - Request Engine中你可以设置线程数Number of threads和请求间隔Throttle。盲目开100个线程狂轰滥炸大概率会触发IP封禁或速率限制。我的习惯是初始枚举如用户名使用较低线程如5-10并设置随机延迟如100-300毫秒低调渗透。确认漏洞后的精准爆破可以适当提高线程如20-30但最好在非业务高峰时段进行。始终监控响应如果突然开始大量收到429 Too Many Requests或403 Forbidden立即暂停大幅增加延迟或更换IP。