2026-05-16 05:38:53 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文介绍了BurpSuite2025.9.5版本新增的自定义扫描检查功能，该功能支持使用类似Java的语言编写扫描规则，比BChecks更强大。文章通过三个实际案例（基于时间的反序列化检测、被动序列化对象检测、基于Collaborator的主动检测）演示如何将原有扩展代码移植为自定义脚本，并详细说明了不同检查类型（主动/被动）的实现方法和MontoyaAPI的关键对象使用。 综合评分： 88 文章分类： WEB安全,渗透测试,安全工具,漏洞分析,红队

cover_image

Burp Suite扩展开发：Montoya方法第九部分——自定义扫描检查

幻泉之洲

2026年5月14日 16:58 北京

在小说阅读器读本章

去阅读

Burp Suite新增了”自定义扫描检查”功能，允许用类似Java的语言编写扫描规则，比BChecks更强大。本文用三个实际例子演示如何将之前用扩展实现的检查移植成自定义扫描脚本，包括基于时间的反序列化检测、被动检测和基于Collaborator的检测。

从BChecks到自定义扫描检查

前几篇文章我们聊了怎么扩展Burp的主动和被动扫描器，用Collaborator，还有BChecks。BChecks挺快的，但局限性不小。第八部分[1]里提到，第六部分[2]和第七部分[3]做的主动扫描检查，没有一个能用BChecks实现。原因很简单：BChecks不支持获取响应时间，也没法操作字节数组——而构造payload恰恰需要这些。

从Burp Suite 2025.9.5开始，情况变了。你可以在Burp里直接用类似Java的语言写扫描检查，跟Bambda过滤器差不多。这个新功能跟BChecks一起塞进了新的”自定义扫描检查”（Custom scan checks）标签页。说实话，功能很强大，几乎覆盖了独立扩展的所有能力。当然，复杂场景下用完整的扩展更靠谱，但要是检查逻辑不太复杂、不需要外部库，自定义扫描检查绝对是个好选择（在Extender设置里可以指定一个放Java库的文件夹，不过我还没试过能不能在自定义检查里调用它们）。

自定义扫描检查可以在Burp Suite的Extensions标签页、”Custom scan check”子标签页里管理——创建、启用/禁用、导入/导出、删除都行。这个标签页取代了原来的”BChecks”标签页，因为现在你又能写Java风格的检查，又能写YAML风格的BChecks了。

开发环境和BChecks那篇文章[1]里的一样。有完整的编辑器、语法检查、示例请求/响应测试、专门的Logger、Issue活动日志。具体细节参考Part 8。

自定义扫描检查的类型

Java风格的自定义扫描检查分以下几种：

ACTIVE（主动）：可以主动发送请求探测漏洞。
Per insertion point（每个插入点执行一次）：最常用，往参数、header、cookie里加payload，比如SQL注入探测。
Per request（每个请求执行一次）：操作整个请求或响应，比如替换请求体。
Per host（每个主机执行一次）：只依赖主机信息，比如检查/manager/html管理界面是否存在。
PASSIVE（被动）：分析流量，不发送新请求。
Per request（每个请求执行一次）：分析完整请求/响应，比如检测序列化对象。
Per host（每个主机执行一次）：分析主机级别的属性，比如安全头或Server头信息泄露。

根据插件类型和运行模式，代码里能访问的对象也不一样。查看可用对象的方法如下：

所有插件都有：

HttpRequestResponse（参数requestResponse）：当前分析的请求/响应
MontoyaApi（参数api）：Montoya插件的核心，能访问所有Burp工具

主动插件还能访问Http对象（参数http），用来发送请求（其实用api.http()也能拿到）。另外，每个插入点执行的主动检查还有一个AuditInsertionPoint对象（参数insertionPoint），包含插入点详情和用payload构造目标请求副本的实用函数。

这些对象在Part 6和Part 7里都见过，跟外部扫描器扩展完全一样。所有插件必须返回一个AuditResult对象，里面包含发现的问题——这也跟外部扩展一样。

移植实战：三个检查从扩展到自定义扫描

Part 8里我们试了BChecks，但Part 6和Part 7的检查因为BChecks的限制没法实现。现在用新的Java脚本引擎来移植它们。目标应用还是那个：一个反序列化输入流的Java应用，打包了有漏洞的Apache Commons Collections 3库。样本应用可以在我GitHub仓库[4]下载。部署需要Java应用服务器，我用的Apache Tomcat，配置简单（环境细节见Part 6）。

检查1：基于时间的主动反序列化检测

Part 6里我们用睡眠payload检测Java序列化漏洞。原始扩展代码是这样的：

@Override public AuditResult activeAudit(HttpRequestResponse baseRequestResponse, AuditInsertionPoint auditInsertionPoint){ List activeAuditIssues = new ArrayList(); for(int i = 0; i < apacheCommonsCollections3Payloads.length; i++){ … if(requestWithPayloadTimingMs.toMillis() >= 9000){ AuditIssue auditIssue = AuditIssue.auditIssue(…); activeAuditIssues.add(auditIssue); } } return AuditResult.auditResult(activeAuditIssues); }

这是按每个插入点执行的主动检查。移植后的自定义扫描检查代码如下：

/** * Check for exploitable Java serialization issues with Apache Commons Collections 3 library (using time). * @author apps3c **/ String[] apacheCommonsCollections3Payloads = new String[]{“rO0[…]fgA5”, “rO0[…]HEAfgAu”, “rO0A[…]AHh4eA==”, “rO0[…]J4”}; List activeAuditIssues = new ArrayList(); for(int i = 0; i < apacheCommonsCollections3Payloads.length; i++){ … HttpRequestResponse commonsCollectionsCheckRequestResponse = http.sendRequest(commonsCollectionsCheckRequest); Optional requestWithPayloadTiming = commonsCollectionsCheckRequestResponse.timingData(); if(requestWithPayloadTiming.isPresent()){ Duration requestWithPayloadTimingMs = requestWithPayloadTiming.get().timeBetweenRequestSentAndStartOfResponse(); long timingThresholdMs = 9000; if(requestWithPayloadTimingMs.toMillis() >= timingThresholdMs){ … activeAuditIssues.add(AuditIssue.auditIssue(…)); } } } return AuditResult.auditResult(activeAuditIssues);

代码几乎一样。我只是把payload和问题描述直接写进了检查里（在结构化扩展里可以放外面让代码更清晰），还把计算响应时间的方式微调了一下。之前我是手动算的，因为代码是从我那个基于旧API的Java Deserialization Scanner[5]插件里复制过来的。Montoya API提供了更好的方法——HttpRequestResponse对象里自带了计时信息[6]，旧API里没有。新API里可以这样轻松拿到毫秒数：

HttpRequestResponse commonsCollectionsCheckRequestResponse = http.sendRequest(commonsCollectionsCheckRequest); Optional requestWithPayloadTiming = commonsCollectionsCheckRequestResponse.timingData(); if(requestWithPayloadTiming.isPresent()){ Duration requestWithPayloadTimingMs = requestWithPayloadTiming.get().timeBetweenRequestSentAndStartOfResponse(); long millis = requestWithPayloadTimingMs.toMillis(); }

检查2：被动检测序列化对象

Part 6里还有一个被动检查，在HTTP请求中查找序列化对象。原始代码：

@Override public AuditResult passiveAudit(HttpRequestResponse baseRequestResponse){ List passiveAuditIssues = new ArrayList(); ByteArray request = baseRequestResponse.request().toByteArray(); int indexOfSerializationMagicBytes = request.indexOf(ByteArray.byteArray(serializationMagicBytes)); int indexOfBase64MagicBytes = request.indexOf(ByteArray.byteArray(base64MagicBytes)); if(indexOfSerializationMagicBytes != -1 || indexOfBase64MagicBytes != -1){ … passiveAuditIssues.add(auditIssue); } return AuditResult.auditResult(passiveAuditIssues); }

这是按每个请求执行的被动检查。移植后的代码：

/** * Passively detect serialized object (raw or base64 encoded in HTTP requests) * @author apps3c **/ byte[] serializationMagicBytes = {(byte)0xac, (byte)0xed, (byte)0x00, (byte)0x05}; byte[] base64MagicBytes = {(byte)0x72, (byte)0x4f, (byte)0x30, (byte)0x41}; ByteArray request = requestResponse.request().toByteArray(); int indexOfSerializationMagicBytes = request.indexOf(ByteArray.byteArray(serializationMagicBytes)); int indexOfBase64MagicBytes = request.indexOf(ByteArray.byteArray(base64MagicBytes)); if(indexOfSerializationMagicBytes != -1 || indexOfBase64MagicBytes != -1){ … return AuditResult.auditResult(AuditIssue.auditIssue(…)); } else { return AuditResult.auditResult(); }

一样没什么大改。我只用了httpRequestReponse对象。

检查3：基于Collaborator的主动反序列化检测

Part 7里我们用Collaborator通过DNS交互检测序列化漏洞，而不是靠时间。原始代码包含一个辅助方法来构造payload（因为序列化对象里要嵌入变长的Collaborator URL，得调整几个二进制的长度字段）。然后主动检查方法里调用它。移植后的自定义检查代码：

/** * Check for exploitable Java serialization issues with Apache Commons Collections 3 library (using Collaborator). * @author apps3c **/ String[] apacheCommonsCollections3Payloads = new String[]{“rO0[…]ADc=”, “rO0[…]4ALg==”, “rO0[…]AB4eA==”, “rO0[…]AAAeHh4”, “rO0[…]AAng=”}; List activeAuditIssues = new ArrayList(); CollaboratorClient collaboratorClient = api.collaborator().createClient(); Utilities utilities = api.utilities(); for(int i = 0; i < apacheCommonsCollections3Payloads.length; i++){ … // 辅助方法createDnsPayload直接写在检查里，逻辑不变 … List interactionList = collaboratorClient.getInteractions(InteractionFilter.interactionPayloadFilter(collaboratorURL)); if(interactionList.size() > 0){ activeAuditIssues.add(AuditIssue.auditIssue(…)); } } return AuditResult.auditResult(activeAuditIssues);

跟前两个例子一样，几乎没变化。辅助方法直接搬进了检查里。这次除了httpRequestResponse、insertionPoint和http，还用了api对象来拿Collaborator客户端。

跟往常一样，我们可以定义一个只启用自己检查的自定义扫描配置文件，加快扫描速度。这里我们只想用自定义扫描检查，所以可以把它们启用，然后禁用所有内置检查和扩展检查（这也是个相对新的特性，以前扫描配置文件里没法禁用扩展检查）。

等一会儿，结果就出来了。

自定义扫描检查，到此为止。

完整代码可以在我的GitHub仓库[7]找到。自定义扫描脚本既提供了Java版也提供了Bambda扩展版。Java版需要粘贴到编辑器里，Bambda脚本可以用”导入”功能直接加载。

官方文档和示例：

自定义扫描检查编写指南[8]
官方示例[9]
Montoya API文档[10]

Cheers!

参考资料

[1] https://hnsecurity.it/blog/extending-burp-suite-for-fun-and-profit-the-montoya-way-part-8/

[2] https://hnsecurity.it/blog/extending-burp-suite-for-fun-and-profit-the-montoya-way-part-6/

[3] https://hnsecurity.it/blog/extending-burp-suite-for-fun-and-profit-the-montoya-way-part-7/

[4] https://github.com/federicodotta/Burp-Suite-Extender-Montoya-Course/tree/main

[5] https://github.com/federicodotta/Java-Deserialization-Scanner

[6] https://portswigger.github.io/burp-extensions-montoya-api/javadoc/burp/api/montoya/http/handler/TimingData.html

[7] https://github.com/federicodotta/Burp-Suite-Extender-Montoya-Course

[8] https://portswigger.net/burp/documentation/desktop/extend-burp/custom-scan-checks/creating/writing-guide

[9] https://github.com/PortSwigger/bambdas/tree/main/CustomScanChecks

[10] https://portswigger.github.io/burp-extensions-montoya-api/javadoc/burp/api/montoya/MontoyaApi.html

[11] https://hnsecurity.it/blog/extending-burp-suite-for-fun-and-profit-the-montoya-way-part-9/

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：幻泉之洲《Burp Suite扩展开发：Montoya方法第九部分——自定义扫描检查》