在当前复杂的网络安全环境中，服务器端请求伪造（SSRF）漏洞已成为企业面临的严峻挑战之一。这类漏洞允许攻击者利用服务器发起恶意请求，进而访问内部系统或外部资源，对企业数据安全和业务连续性构成严重威胁。XXL-JOB-admin 调度中心被曝出SSRF漏洞（CVE-2022-43183），再次为我们敲响了警钟。本文将围绕这一典型案例，深入探讨 SSRF 漏洞的原理、复现过程、以及企业应如何构建坚固的防护体系，旨在为广大开发者和安全从业者提供一份全面的技术指南和实践参考。
01
漏洞概览
/ TINGYUN
XXL-JOB 是许雪里（XXL-JOB）社区的一款基于 java 语言的分布式任务调度平台。该项目由3个部分组成，xxl-job-admin 主要提供任务调度中心的web页面，xxl-job-executor-samples 是 xxl-job 执行器的示例代码，xxl-job-core 封装了 xxl-job-admin 和 xxl-job-executor-sample 核心代码。
XXL-JOB v2.3.1 之前版本存在安全漏洞，该漏洞源于组件 /admin/controller/JobLogController.java 中包含服务器端请求伪造（SSRF）。
02
风险自查
/ TINGYUN
为了及时发现并规避潜在风险，企业应立即对当前使用的 xxl-job 版本进行自查。您可以通过听云 ASPM 的组件风险功能或其他专业的安全检测工具，核查您的 xxl-job 版本是否处于以下受影响的范围内：
xxl-job
03
如何修复受影响的程序
/ TINGYUN
升级到 xxl-job 2.4.0 及以上版本：
-
XXL-JOB 3.x 版本开始要求使用 JDK17。对于仍在使用 JDK1.8 的用户，目前支持 JDK1.8 的最新稳定版本是 XXL-JOB 2.5.0。请根据您的实际环境选择合适的升级路径，确保系统兼容性。
04
漏洞的原理及利用
/ TINGYUN
漏洞的原理
理解 SSRF 漏洞的深层原理对于有效防范至关重要。XXL-JOB-admin 调度中心 SSRF 漏洞的产生，源于其在处理执行器调度日志请求时，对执行器 URL 地址的校验不足。
xxl-job 调度中心后台用户在查看执行器调度日志时，请求中会指定执行器的 URL 地址，让调度中心去该 URL 地址的执行器获取调度日志。由于调度中心服务发起对执行器的请求时没有对该url地址进行校验，故恶意攻击者可以指定服务器请求的 URL 地址，导致 xxl-job 调度中心后台存在 SSRF 漏洞。
漏洞复现
1.搭建环境
我们选择 XXL-JOB v2.3.0，笔者为了方便分析源码，用源码搭建，也可以用 Docker 搭建，
源码地址：https://github.com/xuxueli/xxl-job/releases/tag/2.3.0
xxl-job快速入门：https://www.xuxueli.com/xxl-job/#%E4%BA%8C%E3%80%81%E5%BF%AB%E9%80%9F%E5%85%A5%E9%97%A8
//启动 xxj-job-admin
//启动编辑器
至此我们的复现环境准备完毕。
2.登录并执行任务
访问http://{hostip}:8080/xxl-job-admin/登录,然后来到【任务管理】，执行任务（确保我们的执行器已经正确连接到 xxl-job-admin）。
3.查看调度日志并抓取数据包
用 yso-java hack 构造序列化数据任务执行完成后，进入【调度日志】页面，找到刚刚执行的任务日志，并抓取原始数据包。这个数据包将包含 executorAddress 字段，它是 SSRF 漏洞利用的关键。
4.修改数据包并发送请求
修改数据包中的 executorAddress 字段为我们要请求的地址，然后发送请求。
5.验证漏洞利用成功
如果一切顺利，您将在 DNSLOG 平台收到来自 XXL-JOB 调度中心服务器的请求信息，这表明 SSRF 漏洞已成功被利用。
漏洞追踪
为了更深入地理解漏洞的成因，我们对 XXL-JOB 的相关代码进行了追踪分析：
1.参数接收与传递
观从 POST
/xxl-job-admin/joblog/logDetailCat
接口接收 String executorAddress 参数，
然后直接带入到
XxlJobScheduler.getExecutorBiz(executorAddress) 中执行。
2.缺乏安全校验
通过观察 XxlJobScheduler.java,发现传入的 executorAddress 没有经过特别的安全校验，返回了接口类 executorBiz。
3.接口类功能定义
接口类 executorBiz 中定义了远程执行器应该具备的功能（心跳、触发任务、kill、日志等）。其中日志功能有两个实现类，其中 ExecutorBizClinent 下面会提到的。
4.日志方法调用
接下来我们回到原来的代码，进入下一步，这时候调用了接口类 executorBiz 的 log 方法。
5.ExecutorBizClient 的初始化与拼接
我们找到 executorBiz 的实现类 ExecutorBizeClient，调用 log 函数前的初始化步骤，会通过构造函数在每一个 addresssUrl 后面加一个“/”，然后返回 XxlJobRemotingUtil.postBody 的调用结果，还会在初始化后的 addressUrl 拼接“log”，所以实际调用的 addressUrl 应该是http://{addressUrl}/log。
6.直接发起POST请求
接下来我们跟到
XxlJobRemotingUtil.postBody可以看到直接对
url发起了POST请求。
小结：从整条链路上来看，从 POST /xxl-job-admin/joblog/logDetailCat 接口接收用户输入的 executorAddress 字段，只做了一些常规的校验和拼接，没有经过任何安全校验，直接被服务端发起请求，满足了 SSRF 漏洞的利用条件。
05
听云 ASPM 如何提供帮助
/ TINGYUN
面对日益复杂的网络安全威胁，专业的应用安全性能管理（ASPM）工具显得尤为重要。听云 ASPM 用户可以通过威胁感知，组件风险，来实时观察自己的系统是否存在依赖 0day 安全风险以及 1day 或 nday 的组件风险。针对上述 xxl-job 漏洞，听云 ASPM 能够发挥以下关键作用：
SSRF漏洞发现
当 xxl-job-admin 通过听云探针插桩后，恶意攻击者尝试 SSRF 攻击，听云 ASPM 能够立即发现 SSRF 漏洞。
威胁感知详情
通过 ASPM，用户可以看到 SSRF 攻击的请求信息和堆栈信息，帮助企业快速定位触发漏洞的位置。
威胁感知详情-修复方案
ASPM 还提供 SSRF 漏洞的原理解析和修复示例，帮助开发人员理解和修复漏洞。
06
企业如何应对SSRF漏洞：
/ TINGYUN
在企业 Web 应用开发过程中，开发者常常会忽视对用户输入的安全校验，从而引发 SSRF 漏洞。例如，《CVE-2022-43183 XXL-JOB-admin 调度中心 SSRF 漏洞》就是典型案例。应对这类问题的核心在于确保请求地址的可信性：pache Tomcat 反序列化漏洞（CVE-2025-24813）的曝光，再次凸显了在当前复杂多变的网络环境中，开发人员定期更新依赖项、检查安全架构以及部署专业安全工具的重要性。这一事件不仅是对技术人员的一次警醒，也证明了听云 ASPM 类型应用安全性能管理工具在 0day 漏洞防护、组件安全等应用安全领在企业 Web 应用开发过程中，开发者常常会忽视对用户输入的安全校验，从而引发 SSRF 漏洞。例如，《CVE-2022-43183 XXL-JOB-admin 调度中心 SSRF 漏洞》就是典型案例。应对这类问题的核心在于确保请求地址的可信性：域中的不可替代作用。只有持续关注安全动态，积极采取防护措施，才能在网络空间中筑牢坚实的防线，确保业务的持续稳定运行。
严格的输入校验：
如果请求地址由用户提供，应通过严格的安全校验，例如结合白名单与黑名单机制。
数据库入库前校验：
如果请求地址来源于服务器数据库，则需要在入库前就进行安全校验，确保其合法性与安全性。
网络策略限制：
通过合理的网络策略配置限制敏感资源访问，例如在防火墙、Nginx、云安全组中阻断应用对内部管理端口、元数据服务（如 169.254.169.254）及非必要外网地址的访问，从而降低 SSRF 攻击利用的可能性。
借助专业工具：
借助专业的应用安全性能管理（ASPM）工具， 企业能够及时发现和追踪应用中的安全缺陷，从而有效筑牢整体安全防线。
【CVE-2022-43183 XXL-JOB-admin 调度中心 SSRF 漏洞】的曝光，再次提醒我们 SSRF 漏洞的普遍性和危害性。面对日益严峻的网络安全形势，企业必须从开发、部署到运维的各个环节，全面加强安全防护。通过严格的输入校验、合理的网络策略配置以及引入专业的 ASPM 工具，企业能够有效抵御 SSRF 等各类安全威胁，确保业务的持续稳定运行。
参考：
https://github.com/xuxueli/xxl-job/issues/3002
声明：
本文的所有漏洞环境均为本地测试环境，且本文仅供学习、安全研究参考使用，请勿用作违法用途，否则后果自负。
推荐阅读
