1. 项目概述BurpBounty是什么以及它为何值得你投入时间如果你是一名渗透测试工程师或者安全研究员并且日常工作中重度依赖Burp Suite那么你很可能已经对内置的主动和被动扫描器又爱又恨。爱的是它开箱即用恨的是它经常漏报一些特定漏洞或者对某些新型攻击载荷的检测能力不足。这时候一个能让你自定义扫描规则的工具就显得至关重要。BurpBounty正是为了解决这个痛点而生的。它不是一个全新的扫描器而是一个功能强大的Burp Suite扩展官方称之为“扫描检查构建器”。简单来说它为你提供了一个图形化界面让你可以像搭积木一样创建属于你自己的漏洞检测规则从而极大地增强Burp Suite原生扫描器的能力。我第一次接触BurpBounty是在一次针对某大型Web应用的测试中Burp自带的扫描器对一处潜在的服务器端模板注入SSTI毫无反应。手动验证虽然可行但效率低下。后来我通过BurpBounty自定义了一条基于响应时间延迟和特定错误信息匹配的复合规则不仅成功自动化地发现了那个SSTI点还将这条规则固化下来在后续类似框架的测试中屡试不爽。这种“授人以渔”的能力是BurpBounty的核心价值。它把漏洞检测的逻辑从黑盒变成了白盒你将深刻理解扫描器“为什么”会报告一个漏洞因为规则本身就是你亲手定义的。这个项目在GitHub上由wagiro维护获得了超过1.8k的星标这足以说明它在安全社区特别是漏洞赏金猎人群体中的受欢迎程度。它主要服务于那些不满足于通用扫描结果、希望针对特定技术栈、框架或应用逻辑进行深度、精准扫描的安全从业者。无论是想自动化一些重复性的手动检查步骤还是想构建一个针对公司内部技术栈的专属扫描规则库BurpBounty都是一个绝佳的选择。接下来我会结合自己多年的使用经验为你拆解这个工具的核心并重点分享那些官方文档可能没写但在实际使用中一定会遇到的“坑”和解决方案。1.1 核心需求解析为什么我们需要自定义扫描规则在深入细节之前我们得先搞清楚一个问题Burp Suite自带的扫描器已经很强大了为什么我们还要费劲去自定义规则这背后的需求是多层次的。首先漏洞的多样性和时效性。安全漏洞层出不穷特别是逻辑漏洞和针对特定组件如某个Shiro版本、某个Fastjson反序列化链的漏洞。Burp官方的漏洞库更新再快也很难覆盖所有边缘情况和新出现的POC。当你发现一个新型的漏洞利用方式时最快将其转化为自动化检测能力的方法就是通过BurpBounty创建一条规则。其次扫描的精准度和误报控制。通用扫描器为了追求覆盖率往往会采用比较“粗暴”的载荷导致误报率高后期需要大量人工筛选。而通过BurpBounty你可以设计极其精确的匹配条件。例如你可以规定只有当请求参数id被替换为特定Payload并且服务器响应中包含了root:字符串同时响应状态码为200时才报告为一个“潜在的命令注入”。这种多条件组合极大地提升了报告的准确性。再者被动扫描的增强。Burp的被动扫描主要依赖流量分析来发现信息泄露、敏感数据等。但很多敏感信息的模式是业务相关的比如内部API的特定错误信息、测试环境的域名特征等。通过BurpBounty你可以轻松添加针对这些特征的被动扫描规则让Burp在后台浏览时就能自动标记出这些问题。最后工作流程的自动化与知识沉淀。安全测试中有大量重复性的检查工作比如检查所有输入点是否存在SQL注入、XSS、路径遍历等。虽然这些Burp能扫但你可能有一套自己更偏好的Payload或更相信的检测逻辑。通过BurpBounty你可以将个人或团队的最佳实践固化成“扫描配置文件”一次创建多次复用。这不仅是效率工具更是团队知识资产的积累。1.2 核心功能与架构初探BurpBounty从架构上紧密集成在Burp Suite中主要通过与Scanner组件交互来工作。它的核心功能模块可以概括为以下几点配置文件管理这是BurpBounty的规则载体以.bb为后缀的文件。一个配置文件里可以包含多条针对不同漏洞类型或检测场景的规则。规则编辑器GUI核心提供直观的图形界面让你定义“扫描检查”。主要包括攻击Attack定义要发送的Payload。可以是简单的字符串列表也可以是基于Battering Ram、Pitchfork等Payload位置的复杂插入。匹配Match定义如何判断漏洞存在。这是最核心的部分支持多种条件字符串匹配在响应中查找特定字符串支持正则表达式。状态码匹配检查响应状态码。响应时间匹配检测是否存在时间延迟用于盲注类漏洞。Burp Collaborator交互检测是否存在带外OOB数据交互用于盲打类漏洞。执行位置选择规则应用于主动扫描Active Scan还是被动扫描Passive Scan。扫描引擎集成创建好的规则会被打包成Burp Suite能识别的格式当启动主动或被动扫描时这些自定义规则会和内置规则一同执行。社区共享由于配置文件是文本格式社区用户可以轻松分享自己创建的.bb文件。上文提到的Six2dez1整理的 profiles 合集就是一个宝库里面包含了大量针对常见漏洞和流行组件的检测规则能让你事半功倍。理解了这个架构你就明白了BurpBounty本质上是一个“规则翻译器”和“引擎插件”。它把你的检测逻辑用GUI定义翻译成Burp扫描引擎能执行的指令。接下来我们就进入实战环节看看如何从零开始打造一条属于自己的规则。2. 核心细节解析与实操要点打造你的第一条检测规则纸上得来终觉浅绝知此事要躬行。要真正掌握BurpBounty最好的方法就是亲手创建一条规则。我们以一个相对简单但非常经典的场景为例检测基于响应内容的SQL注入漏洞。假设我们要检测一种情况当向参数注入单引号‘时如果响应中出现了SQL syntax或MySQL等数据库错误信息则报告漏洞。2.1 环境准备与安装避坑首先你需要一个正常运行的Burp Suite专业版或社区版均可。BurpBounty的安装有两种主要方式方式一通过BApp Store安装推荐给新手在Burp Suite中切换到Extender标签页然后点击BApp Store。在商店列表中搜索Burp Bounty找到后点击Install即可。这是最省事的方法Burp会自动处理依赖和更新。注意Burp Suite的BApp Store有时会因为网络问题无法加载。如果遇到此情况可以尝试检查Burp的代理设置是否正确或者暂时将Burp设置为直连模式Proxy - Options - Proxy Listeners - Edit - 取消勾选Support invisible proxying...下的选项并尝试Request upstream proxy authentication等。如果实在无法访问则采用手动安装。方式二手动加载Jar文件适用于所有场景从项目的GitHub Releases页面https://github.com/wagiro/BurpBounty/releases/下载最新版本的BurpBounty.jar文件。在Burp Suite中切换到Extender标签页点击Add。在Extension Details中Extension type选择Java。点击Select file...选择你下载的BurpBounty.jar。点击NextBurp会加载扩展。如果一切正常你会看到输出日志显示加载成功并且Burp的顶部菜单栏会出现一个新的Burp Bounty选项卡。实操心得我强烈建议即使通过BApp Store安装也保留一份下载的Jar文件。因为在某些隔离网络环境中进行测试时Burp可能无法访问外网更新BApp。手动加载Jar是更可靠的备用方案。另外确保你的Java环境是较新的版本如JDK 8或11过旧的Java版本可能导致兼容性问题。安装成功后点击Burp Bounty选项卡你会看到主界面。界面主要分为三块顶部的菜单栏、左侧的配置文件列表、右侧的规则编辑和详情区域。第一次使用左侧列表可能是空的。2.2 创建第一个配置文件与规则我们的目标是创建一个名为My_SQL_Error_Based.bb的配置文件里面包含一条检测SQL错误注入的规则。新建配置文件点击菜单栏的Profiles-New Profile。在弹出的对话框中给配置文件起个名字比如My_SQL_Error_Based描述可以写Detect SQL injection via error messages。点击OK后你会在左侧列表看到它。添加新规则在左侧选中你新建的配置文件然后在右侧区域点击New Scan Check按钮。这会打开规则编辑窗口这里面的选项很多我们一步步来。规则信息InfoName给这条规则起个易懂的名字如SQL Error Detection (Single Quote)。Enabled务必勾选否则规则不会执行。Issue Detail这里填写当漏洞被发现时报告里会显示的详细信息。可以描述漏洞原理、影响和修复建议。例如“应用程序在处理用户输入时未正确过滤导致SQL查询语法被改变。攻击者可能利用此漏洞查看、修改或删除数据库数据。建议使用参数化查询或预编译语句。”Issue Type选择漏洞类型这里选SQL injection。攻击设置Attack这里定义我们发送的Payload。Attack type选择Simple list因为我们只需要测试一个简单的单引号。在下方的大文本框中输入我们的Payload‘就是一个单引号。你可以点击Add按钮添加更多比如‘‘两个单引号、\‘转义单引号等但第一条规则我们先保持简单。PlacementPayload插入的位置。对于检测参数注入通常选择url-parameter-valueURL参数值和body-parameter-value请求体参数值。为了全面我们可以都选上或者根据实际情况选择。匹配设置Match——核心中的核心这里定义如何判断漏洞存在。Match type选择Simple string match简单字符串匹配。对于错误信息检测这通常就足够了。Match condition选择If all matches are true与逻辑或If any match is true或逻辑。因为我们期望响应中包含某些关键词所以选择If any match is true更合适只要命中一个关键词就认为匹配。在下方区域点击Add来添加我们要匹配的字符串。这里就是我们的“指纹”库。添加以下几项每项一行SQL syntax MySQL You have an error in your SQL syntax Warning: mysql PostgreSQL ORA-[0-9] Unclosed quotation markCase sensitive通常不勾选因为数据库错误信息大小写可能不一致。Exclude matches排除匹配。如果你发现某个页面正常返回就包含SQL这个词比如页面内容本身在讲SQL可以在这里添加排除项避免误报。执行设置ExecutionExecute during选择Active Scan。因为我们需要主动发送带有Payload的请求来触发错误。Attack Insert Point保持默认或根据你的Placement选择调整。Scope你可以选择规则只在特定URL范围内执行。初期可以先选All URLs。保存点击右下角的Save按钮。至此你的第一条规则就创建好了。注意事项规则创建后它只是保存在BurpBounty的配置中并没有自动加载到Burp的扫描器里。你需要点击主界面的Save按钮或者Profiles-Save Profile将整个配置文件保存到磁盘.bb文件然后最关键的一步点击Load profile into Burp Scanner按钮。只有这样Burp Suite的扫描引擎才会在下次扫描时使用这条规则。这是一个非常容易忽略的步骤很多新手以为保存了就生效了其实不然。2.3 测试与调试你的规则规则创建好了怎么知道它是否工作盲目的等待扫描结果不是好习惯。BurpBounty提供了便捷的测试功能。在Burp中用浏览器或者Repeater工具访问一个你认为可能存在SQL注入漏洞的测试点比如一个带有id1的URL。将整个HTTP请求从Burp的Proxy history或Repeater中复制。回到BurpBounty界面在规则列表中找到你刚创建的规则右键点击选择Test this check。在弹出的窗口中将复制的HTTP请求粘贴到Request框。点击Test按钮。BurpBounty会使用你定义的Payload替换请求中的相应位置发送请求并分析响应。在Response框你会看到服务器返回的实际内容。更重要的是下方的Result区域会显示匹配结果。如果规则命中即响应中包含了我们定义的错误关键词你会看到绿色的Match提示并显示具体匹配到的字符串。如果没有命中则是红色提示。这个测试功能极其重要它让你能在规则投入大规模扫描前进行精准的验证和调试。你可以反复修改Payload和匹配条件直到规则能稳定、准确地检测出目标漏洞为止。3. 实操过程与核心环节实现从简单匹配到高级技巧掌握了基础规则创建后我们来探讨一些更高级、更实用的场景和配置技巧。BurpBounty的强大之处在于其匹配条件的灵活组合这能让你的检测逻辑变得非常智能。3.1 实现时间盲注Time-Based Blind SQLi检测基于错误信息的注入检测有明显回显但时间盲注没有。它的原理是注入一个能导致数据库执行延迟的Payload如SLEEP(5)然后观察响应时间是否显著增加。在BurpBounty中实现这个检测关键就在于响应时间匹配Response time match。创建新规则命名为Time-Based SQLi Detection。攻击设置Payload列表里放入典型的时间盲注Payload。例如‘ AND SLEEP(5)-- ‘ AND 1(SELECT COUNT(*) FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMADATABASE() AND SLEEP(5))--注意Payload需根据目标数据库类型调整这里是MySQL示例。匹配设置这是关键。Match type选择Response time match。Condition选择Is greater than大于。Time (ms)设置一个阈值比如50005秒。这个值需要根据目标站点的正常响应时间来设定。通常我会先发送一个正常请求在Repeater中查看响应时间如200ms然后将阈值设置为正常时间的2-3倍以上如1000ms以避免网络波动造成的误报。Compare with选择Original request。这意味着Burp会先发送一个原始请求不带Payload记录基准响应时间然后发送Payload请求比较两者时间差。组合匹配提高准确性单纯依靠时间延迟可能有误报比如服务器临时卡顿。我们可以结合状态码来增加可信度。点击Add match按钮新增一条匹配条件。第二条的Match type选择Status code match。Condition选择Is equal to等于。Status code填入200。因为时间盲注成功时页面通常仍会正常返回200状态码只是响应慢了。回到主匹配设置将Match condition改为If all matches are true。这样规则要求同时满足响应时间大于5秒且状态码为200才报告漏洞大大降低了误报率。3.2 利用Burp Collaborator检测带外OOB漏洞这是检测盲注、SSRF、XXE等无回显漏洞的终极武器。Burp Collaborator是Burp Suite提供的一个带外交互检测服务。规则原理是让目标服务器在处理我们的Payload时向一个我们控制的Collaborator域名发起网络请求DNS查询或HTTP请求。确保Collaborator可用在Burp Suite的Project options-Misc-Burp Collaborator server中确保配置正确通常使用默认的公共服务器或自建服务器。创建新规则命名为OOB DNS/HTTP Detection。攻击设置Payload需要包含一个唯一的Collaborator子域名。BurpBounty支持变量§collaborator§。例如对于DNS带外检测Payload可以是‘||(SELECT LOAD_FILE(CONCAT(‘\\\\’,‘§collaborator§‘,‘.example.com\\’)))--。BurpBounty在发送请求时会自动将§collaborator§替换为一个随机生成的子域名。匹配设置Match type选择Collaborator interaction。这里通常不需要额外配置。规则引擎会自动轮询Collaborator服务器检查是否有来自目标服务器的交互记录。执行当扫描执行时如果目标服务器执行了Payload中的带外请求Burp Collaborator就会收到记录从而触发漏洞报告。实操心得OOB检测非常强大但需要注意两点。第一它依赖于目标服务器能够出网发起DNS或HTTP请求。第二公共Collaborator服务器可能被防火墙屏蔽。在内网测试时自建Collaborator服务器是更可靠的选择。配置方法是在Burp中设置Collaborator server为Use private Collaborator server并指定服务器地址。3.3 管理、导入与分享配置文件当你创建了多条规则后良好的管理习惯能提升效率。分组管理你可以在一个.bb配置文件内创建多条规则也可以为不同漏洞类型如SQLi、XSS、SSRF创建不同的配置文件。建议按功能或项目分类方便启用和禁用。导入社区规则如前所述社区有很多现成的规则集。下载这些.bb文件后在BurpBounty主界面点击Profiles-Load Profile选择文件即可导入。导入后同样需要点击Load profile into Burp Scanner使其生效。规则优化不要盲目添加大量规则这会导致扫描时间剧增。定期审查规则的有效性关闭那些在目标环境中不可能存在的漏洞检测规则例如目标明确是Java应用可以关闭针对PHP特定函数的规则。在Scope中设置合理的URL范围也能显著提升扫描效率。4. 常见问题与排查技巧实录即使理解了原理在实际使用BurpBounty时你依然会遇到各种各样的问题。下面是我和同事们多年踩坑积累下来的经验希望能帮你少走弯路。4.1 规则创建了但扫描时完全不触发这是最常见的问题。请按照以下清单逐一排查规则是否启用Enabled在规则编辑界面和主界面的规则列表中双重确认。配置文件是否加载到扫描器这是最容易被忽略的一步创建或修改规则后必须在主界面点击Load profile into Burp Scanner按钮。你可以通过查看Burp的Extender-Extensions- 选中BurpBounty - 点击Output标签观察加载日志来确认。扫描范围Scope是否正确检查规则的Scope设置是否包含了你的目标URL。可以在Burp的Target-Scope中设置全局范围但规则自身的Scope优先级更高。攻击插入点Placement是否匹配如果你的规则只定义了url-parameter-value但漏洞点在JSON请求体或Cookie中规则自然不会触发。确保Placement覆盖了所有可能的注入点。主动扫描配置在Burp的Scanner-Scan configuration中确保你使用的扫描配置如Default包含了Burp Bounty checks。你可以编辑扫描配置在Active Scanning的Plugin Selection里查看。4.2 规则误报率太高误报是自动化扫描的顽疾。通过精细调整匹配条件可以极大改善。使用“与AND”逻辑和排除项不要只依赖一个匹配条件。结合状态码、响应长度、特定字符串的缺失Exclude matches等多重条件。例如检测XSS时除了匹配scriptalert还可以要求响应状态码为200并且排除掉那些本来就是错误页面的响应通过排除Error Page等字符串。优化正则表达式字符串匹配尽量使用更精确的正则表达式而不是简单的子串匹配。例如匹配SQL错误用You have an error in your SQL syntax比只用syntax更准确。利用“原始响应Raw Response”匹配有时页面HTML里有关键词但渲染后看不到。确保匹配是针对原始HTTP响应进行的。BurpBounty默认就是如此。设置置信度Confidence在规则编辑的Info部分可以设置Issue severity和Confidence。对于容易误报的规则可以将其置信度设为Tentative试探性的这样在结果中会区别显示便于人工复核。进行基线测试在正式扫描前先对目标应用的一个已知安全页面运行你的规则测试使用Test this check。如果规则在安全页面上也触发说明匹配条件太宽泛需要调整。4.3 扫描速度异常缓慢BurpBounty规则执行是串行且可能发送大量请求的配置不当会拖慢整个扫描。减少Payload数量在Attack设置中评估Payload列表是否必要。能用3个关键Payload检测出来的就不要放30个。合理使用“Grep”型规则对于被动扫描规则Execute during: Passive Scan它只分析流量不发送新请求对性能影响极小。应尽可能将那些只需要分析响应内容的检测如敏感信息泄露、特定错误头设置为被动规则。限制扫描范围通过Scope严格控制规则的生效范围避免对静态资源如图片、CSS、第三方域名进行无意义的扫描。分批次扫描不要一次性启用所有配置文件。可以根据测试阶段分批启用。例如初期先运行信息收集和快速检测类规则深度测试时再启用那些耗时较长的盲注检测规则。4.4 与其他Burp扩展的兼容性问题Burp Suite可以加载很多扩展冲突偶有发生。内存占用BurpBounty和类似的自定义扫描扩展如Custom Scanner Checks可能会同时修改扫描引擎增加内存消耗。如果遇到Burp频繁卡顿或崩溃尝试禁用一些扩展或增加Burp启动时的JVM堆内存参数例如在启动脚本中添加-Xmx4G。逻辑冲突极少情况下两个扩展定义的扫描逻辑可能冲突。如果发现某个漏洞只有用A扩展能扫出用B扩展扫不出或者同时启用时行为异常需要隔离测试。通常的解决方法是在测试关键任务时只保留最必要的扩展。4.5 高级功能使用中的“坑”Battering Ram和Pitchfork攻击类型这些用于同时替换多个位置的参数。使用时务必清楚每个Payload列表与参数位置的对应关系否则Payload会错位导致检测无效。建议先在Repeater中手动模拟测试成功再将Payload列表和配置移植到BurpBounty中。响应时间匹配的阈值设置Response time match的阈值是一门艺术。设置太低如比正常响应时间多100ms容易误报设置太高如10秒则扫描效率极低且可能漏报那些延迟较短的漏洞。我的经验是先采集10个正常请求的响应时间取平均值并计算标准差将阈值设置为平均值 3 * 标准差 500ms。这是一个相对科学的动态阈值思路虽然BurpBounty不支持自动计算但你可以手动估算。正则表达式性能在匹配条件中使用复杂的正则表达式尤其是包含.*的贪婪匹配去匹配大体积的响应体会严重消耗CPU资源。尽量使用更精确的表达式或者结合字符串匹配先缩小范围。最后保持更新。关注BurpBounty的GitHub页面新版本可能会修复旧版的Bug或引入更强大的功能。同时多逛逛安全社区学习别人分享的优质.bb配置文件这是快速提升你检测能力的最佳途径。记住工具的价值永远取决于使用它的人。BurpBounty给了你一把锋利的雕刻刀但最终能创造出什么作品还得看你对漏洞原理和检测逻辑的理解深度。
BurpBounty自定义扫描规则：从原理到实战，提升Burp Suite漏洞检测精准度
发布时间：2026/7/7 23:37:12
1. 项目概述BurpBounty是什么以及它为何值得你投入时间如果你是一名渗透测试工程师或者安全研究员并且日常工作中重度依赖Burp Suite那么你很可能已经对内置的主动和被动扫描器又爱又恨。爱的是它开箱即用恨的是它经常漏报一些特定漏洞或者对某些新型攻击载荷的检测能力不足。这时候一个能让你自定义扫描规则的工具就显得至关重要。BurpBounty正是为了解决这个痛点而生的。它不是一个全新的扫描器而是一个功能强大的Burp Suite扩展官方称之为“扫描检查构建器”。简单来说它为你提供了一个图形化界面让你可以像搭积木一样创建属于你自己的漏洞检测规则从而极大地增强Burp Suite原生扫描器的能力。我第一次接触BurpBounty是在一次针对某大型Web应用的测试中Burp自带的扫描器对一处潜在的服务器端模板注入SSTI毫无反应。手动验证虽然可行但效率低下。后来我通过BurpBounty自定义了一条基于响应时间延迟和特定错误信息匹配的复合规则不仅成功自动化地发现了那个SSTI点还将这条规则固化下来在后续类似框架的测试中屡试不爽。这种“授人以渔”的能力是BurpBounty的核心价值。它把漏洞检测的逻辑从黑盒变成了白盒你将深刻理解扫描器“为什么”会报告一个漏洞因为规则本身就是你亲手定义的。这个项目在GitHub上由wagiro维护获得了超过1.8k的星标这足以说明它在安全社区特别是漏洞赏金猎人群体中的受欢迎程度。它主要服务于那些不满足于通用扫描结果、希望针对特定技术栈、框架或应用逻辑进行深度、精准扫描的安全从业者。无论是想自动化一些重复性的手动检查步骤还是想构建一个针对公司内部技术栈的专属扫描规则库BurpBounty都是一个绝佳的选择。接下来我会结合自己多年的使用经验为你拆解这个工具的核心并重点分享那些官方文档可能没写但在实际使用中一定会遇到的“坑”和解决方案。1.1 核心需求解析为什么我们需要自定义扫描规则在深入细节之前我们得先搞清楚一个问题Burp Suite自带的扫描器已经很强大了为什么我们还要费劲去自定义规则这背后的需求是多层次的。首先漏洞的多样性和时效性。安全漏洞层出不穷特别是逻辑漏洞和针对特定组件如某个Shiro版本、某个Fastjson反序列化链的漏洞。Burp官方的漏洞库更新再快也很难覆盖所有边缘情况和新出现的POC。当你发现一个新型的漏洞利用方式时最快将其转化为自动化检测能力的方法就是通过BurpBounty创建一条规则。其次扫描的精准度和误报控制。通用扫描器为了追求覆盖率往往会采用比较“粗暴”的载荷导致误报率高后期需要大量人工筛选。而通过BurpBounty你可以设计极其精确的匹配条件。例如你可以规定只有当请求参数id被替换为特定Payload并且服务器响应中包含了root:字符串同时响应状态码为200时才报告为一个“潜在的命令注入”。这种多条件组合极大地提升了报告的准确性。再者被动扫描的增强。Burp的被动扫描主要依赖流量分析来发现信息泄露、敏感数据等。但很多敏感信息的模式是业务相关的比如内部API的特定错误信息、测试环境的域名特征等。通过BurpBounty你可以轻松添加针对这些特征的被动扫描规则让Burp在后台浏览时就能自动标记出这些问题。最后工作流程的自动化与知识沉淀。安全测试中有大量重复性的检查工作比如检查所有输入点是否存在SQL注入、XSS、路径遍历等。虽然这些Burp能扫但你可能有一套自己更偏好的Payload或更相信的检测逻辑。通过BurpBounty你可以将个人或团队的最佳实践固化成“扫描配置文件”一次创建多次复用。这不仅是效率工具更是团队知识资产的积累。1.2 核心功能与架构初探BurpBounty从架构上紧密集成在Burp Suite中主要通过与Scanner组件交互来工作。它的核心功能模块可以概括为以下几点配置文件管理这是BurpBounty的规则载体以.bb为后缀的文件。一个配置文件里可以包含多条针对不同漏洞类型或检测场景的规则。规则编辑器GUI核心提供直观的图形界面让你定义“扫描检查”。主要包括攻击Attack定义要发送的Payload。可以是简单的字符串列表也可以是基于Battering Ram、Pitchfork等Payload位置的复杂插入。匹配Match定义如何判断漏洞存在。这是最核心的部分支持多种条件字符串匹配在响应中查找特定字符串支持正则表达式。状态码匹配检查响应状态码。响应时间匹配检测是否存在时间延迟用于盲注类漏洞。Burp Collaborator交互检测是否存在带外OOB数据交互用于盲打类漏洞。执行位置选择规则应用于主动扫描Active Scan还是被动扫描Passive Scan。扫描引擎集成创建好的规则会被打包成Burp Suite能识别的格式当启动主动或被动扫描时这些自定义规则会和内置规则一同执行。社区共享由于配置文件是文本格式社区用户可以轻松分享自己创建的.bb文件。上文提到的Six2dez1整理的 profiles 合集就是一个宝库里面包含了大量针对常见漏洞和流行组件的检测规则能让你事半功倍。理解了这个架构你就明白了BurpBounty本质上是一个“规则翻译器”和“引擎插件”。它把你的检测逻辑用GUI定义翻译成Burp扫描引擎能执行的指令。接下来我们就进入实战环节看看如何从零开始打造一条属于自己的规则。2. 核心细节解析与实操要点打造你的第一条检测规则纸上得来终觉浅绝知此事要躬行。要真正掌握BurpBounty最好的方法就是亲手创建一条规则。我们以一个相对简单但非常经典的场景为例检测基于响应内容的SQL注入漏洞。假设我们要检测一种情况当向参数注入单引号‘时如果响应中出现了SQL syntax或MySQL等数据库错误信息则报告漏洞。2.1 环境准备与安装避坑首先你需要一个正常运行的Burp Suite专业版或社区版均可。BurpBounty的安装有两种主要方式方式一通过BApp Store安装推荐给新手在Burp Suite中切换到Extender标签页然后点击BApp Store。在商店列表中搜索Burp Bounty找到后点击Install即可。这是最省事的方法Burp会自动处理依赖和更新。注意Burp Suite的BApp Store有时会因为网络问题无法加载。如果遇到此情况可以尝试检查Burp的代理设置是否正确或者暂时将Burp设置为直连模式Proxy - Options - Proxy Listeners - Edit - 取消勾选Support invisible proxying...下的选项并尝试Request upstream proxy authentication等。如果实在无法访问则采用手动安装。方式二手动加载Jar文件适用于所有场景从项目的GitHub Releases页面https://github.com/wagiro/BurpBounty/releases/下载最新版本的BurpBounty.jar文件。在Burp Suite中切换到Extender标签页点击Add。在Extension Details中Extension type选择Java。点击Select file...选择你下载的BurpBounty.jar。点击NextBurp会加载扩展。如果一切正常你会看到输出日志显示加载成功并且Burp的顶部菜单栏会出现一个新的Burp Bounty选项卡。实操心得我强烈建议即使通过BApp Store安装也保留一份下载的Jar文件。因为在某些隔离网络环境中进行测试时Burp可能无法访问外网更新BApp。手动加载Jar是更可靠的备用方案。另外确保你的Java环境是较新的版本如JDK 8或11过旧的Java版本可能导致兼容性问题。安装成功后点击Burp Bounty选项卡你会看到主界面。界面主要分为三块顶部的菜单栏、左侧的配置文件列表、右侧的规则编辑和详情区域。第一次使用左侧列表可能是空的。2.2 创建第一个配置文件与规则我们的目标是创建一个名为My_SQL_Error_Based.bb的配置文件里面包含一条检测SQL错误注入的规则。新建配置文件点击菜单栏的Profiles-New Profile。在弹出的对话框中给配置文件起个名字比如My_SQL_Error_Based描述可以写Detect SQL injection via error messages。点击OK后你会在左侧列表看到它。添加新规则在左侧选中你新建的配置文件然后在右侧区域点击New Scan Check按钮。这会打开规则编辑窗口这里面的选项很多我们一步步来。规则信息InfoName给这条规则起个易懂的名字如SQL Error Detection (Single Quote)。Enabled务必勾选否则规则不会执行。Issue Detail这里填写当漏洞被发现时报告里会显示的详细信息。可以描述漏洞原理、影响和修复建议。例如“应用程序在处理用户输入时未正确过滤导致SQL查询语法被改变。攻击者可能利用此漏洞查看、修改或删除数据库数据。建议使用参数化查询或预编译语句。”Issue Type选择漏洞类型这里选SQL injection。攻击设置Attack这里定义我们发送的Payload。Attack type选择Simple list因为我们只需要测试一个简单的单引号。在下方的大文本框中输入我们的Payload‘就是一个单引号。你可以点击Add按钮添加更多比如‘‘两个单引号、\‘转义单引号等但第一条规则我们先保持简单。PlacementPayload插入的位置。对于检测参数注入通常选择url-parameter-valueURL参数值和body-parameter-value请求体参数值。为了全面我们可以都选上或者根据实际情况选择。匹配设置Match——核心中的核心这里定义如何判断漏洞存在。Match type选择Simple string match简单字符串匹配。对于错误信息检测这通常就足够了。Match condition选择If all matches are true与逻辑或If any match is true或逻辑。因为我们期望响应中包含某些关键词所以选择If any match is true更合适只要命中一个关键词就认为匹配。在下方区域点击Add来添加我们要匹配的字符串。这里就是我们的“指纹”库。添加以下几项每项一行SQL syntax MySQL You have an error in your SQL syntax Warning: mysql PostgreSQL ORA-[0-9] Unclosed quotation markCase sensitive通常不勾选因为数据库错误信息大小写可能不一致。Exclude matches排除匹配。如果你发现某个页面正常返回就包含SQL这个词比如页面内容本身在讲SQL可以在这里添加排除项避免误报。执行设置ExecutionExecute during选择Active Scan。因为我们需要主动发送带有Payload的请求来触发错误。Attack Insert Point保持默认或根据你的Placement选择调整。Scope你可以选择规则只在特定URL范围内执行。初期可以先选All URLs。保存点击右下角的Save按钮。至此你的第一条规则就创建好了。注意事项规则创建后它只是保存在BurpBounty的配置中并没有自动加载到Burp的扫描器里。你需要点击主界面的Save按钮或者Profiles-Save Profile将整个配置文件保存到磁盘.bb文件然后最关键的一步点击Load profile into Burp Scanner按钮。只有这样Burp Suite的扫描引擎才会在下次扫描时使用这条规则。这是一个非常容易忽略的步骤很多新手以为保存了就生效了其实不然。2.3 测试与调试你的规则规则创建好了怎么知道它是否工作盲目的等待扫描结果不是好习惯。BurpBounty提供了便捷的测试功能。在Burp中用浏览器或者Repeater工具访问一个你认为可能存在SQL注入漏洞的测试点比如一个带有id1的URL。将整个HTTP请求从Burp的Proxy history或Repeater中复制。回到BurpBounty界面在规则列表中找到你刚创建的规则右键点击选择Test this check。在弹出的窗口中将复制的HTTP请求粘贴到Request框。点击Test按钮。BurpBounty会使用你定义的Payload替换请求中的相应位置发送请求并分析响应。在Response框你会看到服务器返回的实际内容。更重要的是下方的Result区域会显示匹配结果。如果规则命中即响应中包含了我们定义的错误关键词你会看到绿色的Match提示并显示具体匹配到的字符串。如果没有命中则是红色提示。这个测试功能极其重要它让你能在规则投入大规模扫描前进行精准的验证和调试。你可以反复修改Payload和匹配条件直到规则能稳定、准确地检测出目标漏洞为止。3. 实操过程与核心环节实现从简单匹配到高级技巧掌握了基础规则创建后我们来探讨一些更高级、更实用的场景和配置技巧。BurpBounty的强大之处在于其匹配条件的灵活组合这能让你的检测逻辑变得非常智能。3.1 实现时间盲注Time-Based Blind SQLi检测基于错误信息的注入检测有明显回显但时间盲注没有。它的原理是注入一个能导致数据库执行延迟的Payload如SLEEP(5)然后观察响应时间是否显著增加。在BurpBounty中实现这个检测关键就在于响应时间匹配Response time match。创建新规则命名为Time-Based SQLi Detection。攻击设置Payload列表里放入典型的时间盲注Payload。例如‘ AND SLEEP(5)-- ‘ AND 1(SELECT COUNT(*) FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMADATABASE() AND SLEEP(5))--注意Payload需根据目标数据库类型调整这里是MySQL示例。匹配设置这是关键。Match type选择Response time match。Condition选择Is greater than大于。Time (ms)设置一个阈值比如50005秒。这个值需要根据目标站点的正常响应时间来设定。通常我会先发送一个正常请求在Repeater中查看响应时间如200ms然后将阈值设置为正常时间的2-3倍以上如1000ms以避免网络波动造成的误报。Compare with选择Original request。这意味着Burp会先发送一个原始请求不带Payload记录基准响应时间然后发送Payload请求比较两者时间差。组合匹配提高准确性单纯依靠时间延迟可能有误报比如服务器临时卡顿。我们可以结合状态码来增加可信度。点击Add match按钮新增一条匹配条件。第二条的Match type选择Status code match。Condition选择Is equal to等于。Status code填入200。因为时间盲注成功时页面通常仍会正常返回200状态码只是响应慢了。回到主匹配设置将Match condition改为If all matches are true。这样规则要求同时满足响应时间大于5秒且状态码为200才报告漏洞大大降低了误报率。3.2 利用Burp Collaborator检测带外OOB漏洞这是检测盲注、SSRF、XXE等无回显漏洞的终极武器。Burp Collaborator是Burp Suite提供的一个带外交互检测服务。规则原理是让目标服务器在处理我们的Payload时向一个我们控制的Collaborator域名发起网络请求DNS查询或HTTP请求。确保Collaborator可用在Burp Suite的Project options-Misc-Burp Collaborator server中确保配置正确通常使用默认的公共服务器或自建服务器。创建新规则命名为OOB DNS/HTTP Detection。攻击设置Payload需要包含一个唯一的Collaborator子域名。BurpBounty支持变量§collaborator§。例如对于DNS带外检测Payload可以是‘||(SELECT LOAD_FILE(CONCAT(‘\\\\’,‘§collaborator§‘,‘.example.com\\’)))--。BurpBounty在发送请求时会自动将§collaborator§替换为一个随机生成的子域名。匹配设置Match type选择Collaborator interaction。这里通常不需要额外配置。规则引擎会自动轮询Collaborator服务器检查是否有来自目标服务器的交互记录。执行当扫描执行时如果目标服务器执行了Payload中的带外请求Burp Collaborator就会收到记录从而触发漏洞报告。实操心得OOB检测非常强大但需要注意两点。第一它依赖于目标服务器能够出网发起DNS或HTTP请求。第二公共Collaborator服务器可能被防火墙屏蔽。在内网测试时自建Collaborator服务器是更可靠的选择。配置方法是在Burp中设置Collaborator server为Use private Collaborator server并指定服务器地址。3.3 管理、导入与分享配置文件当你创建了多条规则后良好的管理习惯能提升效率。分组管理你可以在一个.bb配置文件内创建多条规则也可以为不同漏洞类型如SQLi、XSS、SSRF创建不同的配置文件。建议按功能或项目分类方便启用和禁用。导入社区规则如前所述社区有很多现成的规则集。下载这些.bb文件后在BurpBounty主界面点击Profiles-Load Profile选择文件即可导入。导入后同样需要点击Load profile into Burp Scanner使其生效。规则优化不要盲目添加大量规则这会导致扫描时间剧增。定期审查规则的有效性关闭那些在目标环境中不可能存在的漏洞检测规则例如目标明确是Java应用可以关闭针对PHP特定函数的规则。在Scope中设置合理的URL范围也能显著提升扫描效率。4. 常见问题与排查技巧实录即使理解了原理在实际使用BurpBounty时你依然会遇到各种各样的问题。下面是我和同事们多年踩坑积累下来的经验希望能帮你少走弯路。4.1 规则创建了但扫描时完全不触发这是最常见的问题。请按照以下清单逐一排查规则是否启用Enabled在规则编辑界面和主界面的规则列表中双重确认。配置文件是否加载到扫描器这是最容易被忽略的一步创建或修改规则后必须在主界面点击Load profile into Burp Scanner按钮。你可以通过查看Burp的Extender-Extensions- 选中BurpBounty - 点击Output标签观察加载日志来确认。扫描范围Scope是否正确检查规则的Scope设置是否包含了你的目标URL。可以在Burp的Target-Scope中设置全局范围但规则自身的Scope优先级更高。攻击插入点Placement是否匹配如果你的规则只定义了url-parameter-value但漏洞点在JSON请求体或Cookie中规则自然不会触发。确保Placement覆盖了所有可能的注入点。主动扫描配置在Burp的Scanner-Scan configuration中确保你使用的扫描配置如Default包含了Burp Bounty checks。你可以编辑扫描配置在Active Scanning的Plugin Selection里查看。4.2 规则误报率太高误报是自动化扫描的顽疾。通过精细调整匹配条件可以极大改善。使用“与AND”逻辑和排除项不要只依赖一个匹配条件。结合状态码、响应长度、特定字符串的缺失Exclude matches等多重条件。例如检测XSS时除了匹配scriptalert还可以要求响应状态码为200并且排除掉那些本来就是错误页面的响应通过排除Error Page等字符串。优化正则表达式字符串匹配尽量使用更精确的正则表达式而不是简单的子串匹配。例如匹配SQL错误用You have an error in your SQL syntax比只用syntax更准确。利用“原始响应Raw Response”匹配有时页面HTML里有关键词但渲染后看不到。确保匹配是针对原始HTTP响应进行的。BurpBounty默认就是如此。设置置信度Confidence在规则编辑的Info部分可以设置Issue severity和Confidence。对于容易误报的规则可以将其置信度设为Tentative试探性的这样在结果中会区别显示便于人工复核。进行基线测试在正式扫描前先对目标应用的一个已知安全页面运行你的规则测试使用Test this check。如果规则在安全页面上也触发说明匹配条件太宽泛需要调整。4.3 扫描速度异常缓慢BurpBounty规则执行是串行且可能发送大量请求的配置不当会拖慢整个扫描。减少Payload数量在Attack设置中评估Payload列表是否必要。能用3个关键Payload检测出来的就不要放30个。合理使用“Grep”型规则对于被动扫描规则Execute during: Passive Scan它只分析流量不发送新请求对性能影响极小。应尽可能将那些只需要分析响应内容的检测如敏感信息泄露、特定错误头设置为被动规则。限制扫描范围通过Scope严格控制规则的生效范围避免对静态资源如图片、CSS、第三方域名进行无意义的扫描。分批次扫描不要一次性启用所有配置文件。可以根据测试阶段分批启用。例如初期先运行信息收集和快速检测类规则深度测试时再启用那些耗时较长的盲注检测规则。4.4 与其他Burp扩展的兼容性问题Burp Suite可以加载很多扩展冲突偶有发生。内存占用BurpBounty和类似的自定义扫描扩展如Custom Scanner Checks可能会同时修改扫描引擎增加内存消耗。如果遇到Burp频繁卡顿或崩溃尝试禁用一些扩展或增加Burp启动时的JVM堆内存参数例如在启动脚本中添加-Xmx4G。逻辑冲突极少情况下两个扩展定义的扫描逻辑可能冲突。如果发现某个漏洞只有用A扩展能扫出用B扩展扫不出或者同时启用时行为异常需要隔离测试。通常的解决方法是在测试关键任务时只保留最必要的扩展。4.5 高级功能使用中的“坑”Battering Ram和Pitchfork攻击类型这些用于同时替换多个位置的参数。使用时务必清楚每个Payload列表与参数位置的对应关系否则Payload会错位导致检测无效。建议先在Repeater中手动模拟测试成功再将Payload列表和配置移植到BurpBounty中。响应时间匹配的阈值设置Response time match的阈值是一门艺术。设置太低如比正常响应时间多100ms容易误报设置太高如10秒则扫描效率极低且可能漏报那些延迟较短的漏洞。我的经验是先采集10个正常请求的响应时间取平均值并计算标准差将阈值设置为平均值 3 * 标准差 500ms。这是一个相对科学的动态阈值思路虽然BurpBounty不支持自动计算但你可以手动估算。正则表达式性能在匹配条件中使用复杂的正则表达式尤其是包含.*的贪婪匹配去匹配大体积的响应体会严重消耗CPU资源。尽量使用更精确的表达式或者结合字符串匹配先缩小范围。最后保持更新。关注BurpBounty的GitHub页面新版本可能会修复旧版的Bug或引入更强大的功能。同时多逛逛安全社区学习别人分享的优质.bb配置文件这是快速提升你检测能力的最佳途径。记住工具的价值永远取决于使用它的人。BurpBounty给了你一把锋利的雕刻刀但最终能创造出什么作品还得看你对漏洞原理和检测逻辑的理解深度。
