JAVA代码审计之XXL-Job默认token（XVE-2023-21328）分析

注意：

考虑到这个漏洞官方已经公布相关POC，遂也发一下审计复现过程。

笔者复现的时候并没有公开POC，只是简单看了一下JAVA代码，后面发现这个漏洞比较简单，适合初学者学习，于是专门写一篇。这是笔者看到的公告：

这是笔者第一时间看到的图，真开局一张图，好在描述挺详细的，说的是默认的accesstoken，噫，有戏。

笔者也不是傻，当时看到微步的公告，你想，嗯，未公开。于是兴冲冲搜了下github，好像还真的没有。。。

回到正题，XXL-JOB之前是有未授权的漏洞的，就是那个未授权调用执行器(一般是9999端口)执行计划任务那个洞，但是这个描述说的比较模糊，没有说具体是控制中心管理后台的洞还是执行器的，所以还是得看一下代码。

不过首先得简单讲讲xxl-job的逻辑，xxl-job后台可以管理执行器，后台添加的计划任务，实际上会传递给执行器进行执行命令，两者怎么通讯的？当然是HTTP请求啊，早些年的执行器没有配认证，自然是组装HTTP请求直接发过去就完事了啊，当然服务端可以发，攻击者也可以下发啦，毕竟不需要鉴权嘛，这也是前一个未授权RCE漏洞的由来，现在又出现一个默认token的问题，那么必然是二者通讯需要的认证信息啦。

考虑到既然是默认accesstoken嘛，先看看配置文件

在这里哦：

就这？啊？

还真的是默认token，看看代码怎么调用的，直接检索accesstoken。

这部分是相关代码

com/xxl/job/admin/controller/JobApiController.java:50

很简单啊，就从配置文件里读accesstoken，然后判断是不是从HTTP头传递的accesstoken值一致的，如果不对那么就返回wrong

继续跟从请求头取token那段

这里就是设置一个请求头：

XXL-JOB-ACCESS-TOKEN：accesstoken的值

然后组装POST包，传递给后端

已经到这一步了，这是没有认证的执行器：

添加认证后：

So