第一次打开Burp Suite的Intruder模块时,我完全被那些专业术语搞懵了。但经过多次实战后发现,它本质上就是个"自动化请求发送器"——就像你雇了个不知疲倦的助手,能24小时不停向网站发送各种测试数据。想象一下手工测试SQL注入时,你得反复修改URL参数提交请求,而Intruder能自动帮你完成上千次这种重复劳动。
核心配置三要素缺一不可:
实测中最容易踩的坑是忘记勾选"URL-encode payloads",导致特殊字符被服务器直接过滤。有次测试XSS漏洞时,我准备的 payload因为没编码,直接被WAF拦截,白白浪费两小时排查原因。
最适合测试单个参数漏洞,比如检测用户ID是否存在SQL注入。它会按顺序把每个payload轮流放到所有标记位置。我常用它来快速验证盲注漏洞,配置步骤:
但要注意响应时间差异!有次测试延时注入,页面默认加载2秒,注入成功时会延迟到5秒,这种场景就需要开启"Response time"分析功能。
同时向所有标记位置注入相同payload。去年审计某OA系统时,发现其多参数共用同一过滤逻辑,用这个模式快速验证了全局过滤缺陷。典型应用场景:
需要两组严格对应的数据时使用,比如测试"用户名枚举+密码爆破"组合攻击。关键是要确保两个payload列表的行数匹配。我通常会先用Python预处理字典:
python复制# 生成用户名字典和对应密码字典
users = ["admin","test","guest"]
passwords = ["admin123","test123","guest123"]
with open("user.txt","w") as f:
f.write("\n".join(users))
with open("pass.txt","w") as f:
f.write("\n".join(passwords))
最强大的笛卡尔积模式,但使用不当会被封IP。去年在某电商平台测试时,我用这个模式组合手机号和验证码:
原始字典往往需要二次处理,Intruder的Payload Processing就像个多功能加工车间:
有次遇到过滤空格的SQL注入,我配置的处理链:
/*!50000前缀绕过检测Grep功能就像个智能筛子,我常用的过滤组合:
<title>标签内容比对更高级的玩法是设置自动化规则,比如当发现:
针对IDOR漏洞的检测方案:
GET /api/userinfo?id=§1001§去年用这个方法在某SRC挖到高危漏洞,通过遍历id参数获取了上万条用户敏感信息。
常规扫描器很难检测的二阶注入,可以这样测试:
username=§test'-- §关键是要在"Settings"开启"Follow redirections"和"Store responses"。
当需要测试数万次组合时,这些配置能避免被封:
有次渗透测试中,通过这种温和的攻击方式,用12小时完成了50万次密码尝试,最终破解出弱密码。