JeecgBoot安全加固实战：从一键getshell看Web应用漏洞防御

最近安全圈里讨论度最高的一件事，就是Jeecg_Tools v1.0这个工具。号称对着jeecg框架的服务一键getshell，直接把服务器权限打穿，而且操作门槛低到连新手都能跑通。我第一时间搭了一套测试环境去验证，也翻了大量被攻击的现场日志。先说结论：这工具本身不算高端，它就是把散落在各个漏洞库里的利用思路打包成了自动化脚本，真正值钱的是它背后映射出来的JeecgBoot框架在真实部署中的安全欠账。

这篇不是教你怎么用这个工具的。我从防御视角拆解它为什么能打穿、哪些环节最容易被击穿、现在正在跑JeecgBoot的系统该怎么自查和加固。如果你正好在用jeecg框架做项目，或者是运维、蓝队、做代码审计的同学，这篇文章应该能帮你省下不少排查时间。

1. 事件背后：为什么Jeecg_Tools能“一键”打穿

1.1 一键化工具的本质

很多人第一次听到“一键getshell”会觉得这东西很神秘，好像背后有什么了不得的0day。实际上你把它扒开看，就是一个自动化脚本集合，把已知的漏洞利用步骤串成了流水线。攻击工具本身没有魔法，魔法在于它覆盖的漏洞点足够全，而且目标系统足够旧。

Jeecg_Tools这类工具的逻辑很朴素：先识别指纹，确认目标跑的是JeecgBoot；然后挨个探测已知漏洞路径；探到可用入口后自动上传payload、执行命令、建立持久化后门。整个过程不需要人工干预，所以哪怕是个完全不懂渗透的新手，拿到工具也能跑出结果。这也是为什么这类工具一旦在圈子里传开，受害面会迅速扩大——不是攻击者变聪明了，而是攻击成本被打了下来。

1.2 JeecgBoot为什么总被盯上

JeecgBoot是国内使用量很大的低代码开发平台，很多中小公司的后台管理系统、企业内部OA、甚至一些面向用户的业务系统都是基于它快速搭起来的。用户量大，暴露面自然大。

但真正让它成为靶子的原因有三个：

• 版本碎片化严重：很多生产系统用的是两三年前的版本，甚至是从网上找的改版，根本没有同步官方安全补丁。
• 部署姿势随意：不少系统为了省事，直接把服务暴露在公网，后台管理接口也一样，没有任何访问控制。
• 默认配置没改：默认密码、默认路径、默认token生成规则，一键工具最喜欢这种目标。

你可以把JeecgBoot想成一个小区：工具是开锁公司流出去的一串万能钥匙，而大部分业主压根没换过锁芯。工具流行只是结果，锁芯老化才是原因。

1.3 攻击者到底在打什么

从Jeecg_Tools的利用链来看，核心集中在几类问题上：参数拼接导致的注入类漏洞、上传校验不严导致的文件写入、接口鉴权缺失导致的未授权访问。这些东西单独看都不是新东西，但组合在一起，就足够从零打到一个服务器权限。

所以，与其去研究这个工具本身，不如去理解它打的是什么“锁芯”。把锁芯换了，工具再先进也白搭。

2. 漏洞链路拆解：从注入到获取服务器权限

2.1 注入类漏洞的根因

注入漏洞是jeecg框架历史问题里最常见的一类，尤其是SQL注入。根因说穿了就一句话：外部输入被直接拼进了SQL语句。

很多老代码里写SQL喜欢用字符串拼接：

String sql = "SELECT * FROM user WHERE id = " + request.getParameter("id");

这样写的好处是灵活，坏处是灾难。id参数传进来的东西会被当成SQL代码执行，攻击者可以用闭合引号、注释符把原SQL后半段注释掉，再追加自己的查询逻辑。轻则越权读数据，重则通过数据库的写文件能力直接往服务器上写脚本。

正确的姿势是参数化查询：

String sql = "SELECT * FROM user WHERE id = ?"; PreparedStatement ps = connection.prepareStatement(sql); ps.setInt(1, Integer.parseInt(request.getParameter("id")));

参数化之后，传入内容只会被当作值处理，永远不会被当作SQL结构执行。这是最基础也最有效的防线。

2.2 文件上传与解析漏洞

JeecgBoot的后台很多接口涉及文件上传，比如头像、附件、导入模板。老版本的文件上传接口不干净，问题集中在两个点。

第一是后缀校验可以绕过。有些代码只校验Content-Type，攻击者把Content-Type改成image/png，文件名改成shell.jsp就过了。有些代码校验了后缀名单，但是名单是黑名单，只拦了.jsp、.asp，忘了拦.jspx、.jspf，照样绕过。

第二是上传目录和执行目录重叠。很多系统上传文件直接丢在Web应用的可执行目录下，比如webapps/ROOT/upload/，上传的JSP文件一旦被写入，直接访问URL就能执行。这是非常致命的组合拳。

正确的做法是白名单校验：

String whiteList = "jpg,jpeg,png,gif,webp,pdf,doc,docx,xls,xlsx"; String ext = FilenameUtils.getExtension(file.getOriginalFilename()).toLowerCase(); if (!Arrays.asList(whiteList.split(",")).contains(ext)) { throw new RuntimeException("不允许的文件类型"); }

然后强制存储目录放在Web可执行目录之外，通过独立文件服务或者单独的下载接口去读取，保证上传和解析两条路彻底断开。这一点做到位，上传类漏洞基本就堵死了。

2.3 认证与会话管理漏洞

一键工具里还有一类很常见的利用点是对后台接口的未授权访问。很多JeecgBoot自定义接口只在前端做了路由控制，后端接口没有做权限拦截，攻击者直接拼路径就能调到敏感接口。

我见过一个真实案例，某系统的数据导出接口没有鉴权，任何人拿到接口路径就能把整个用户表拖走。这类问题的根源是开发时只考虑了“前端看不见入口就等于安全”，完全忘了很多接口是可以直接构造HTTP请求的。

会话管理方面，老版本也存在可预测的token问题，session固定攻击、默认口令未修改，这些都是工具扫描器的重点探测项。防御思路就一条：所有涉及敏感操作的接口，一律走shiro或spring security的鉴权链路，重复校验身份和权限，绝不能依赖前端隐藏。

2.4 从“getshell”到权限维持

攻击者拿到一个webshell之后，不会停留在那一台机器上。典型的后续动作是：上传内网扫描工具摸清网段，抓取配置文件找数据库账号密码，再用账号密码横向移动到其他服务器。

这个链路提醒我们一个事实：一台边缘服务器的失陷，往往意味着整个内网开始裸奔。所以加固工作不能只盯着Web本身，服务器的基线检查、数据库的访问控制、内网的流量监控都得同步做。

3. 自查你的系统是否已经“中招”

3.1 日志排查的三个关键位置

如果你手上已经有一个正在运行的JeecgBoot系统，第一步不是急着打补丁，而是先确认自己是不是已经被打过了。攻击痕迹一般会留在三个地方：

• Web访问日志：看有没有大量的404扫描请求，尤其是路径里带upload、template、jmx-console、actuator等等特征的请求。攻击者会用这些关键词做路径爆破。
• 应用日志：JeecgBoot的系统日志里会记录SQL执行异常、文件上传异常、权限校验失败。异常密度突然升高，很可能有人正在尝试攻击。
• 服务器系统日志：看有没有非计划的定时任务创建、新增用户、监听异常端口。这几个都是webshell驻留后的常见行为。

3.2 常见的Webshell特征

网上虽然有很多查杀工具，但实战里我建议手工先扫一遍，重点看几个特征：

• 文件内容和文件名明显不匹配，比如一个logo.png打开是密文。
• 文件修改时间集中在某段时间，尤其是半夜。
• 目录里出现外文随机命名的JSP文件，或者加密混淆的长字符串。
• JS文件里混入了执行代码。

Windows服务器可以重点看C:\Windows\Temp和Web应用目录里的时间异常文件；Linux服务器重点看/tmp、/var/tmp和Web目录下的.jsp、.jspx后缀文件。

3.3 快速自查命令

Linux服务器上可以快速过一遍：

find /usr/local/tomcat/webapps -name "*.jsp*" -mtime -7 ls -lt /usr/local/tomcat/webapps/ROOT/upload/ cat /etc/crontab find / -name "*.jsp" -newer /tmp/.checkdate

Windows服务器如果没有现成的查杀工具，建议第一时间部署云安全中心或者杀毒软件做全盘扫描，然后人工核查Web目录里最近七天的上传文件。就算没有查到确凿的webshell，也不代表没被攻击，只说明痕迹可能被清理了。

4. 系统加固：修复漏洞根治“一键getshell”

4.1 升级框架版本

Jeecg_Tools能打穿的系统，绝大多数是老版本。官方在新版本里针对已知漏洞做了大量修复，所以最有效的加固动作就是升级到最新版。升级之前先备份数据库和配置文件，然后先在测试环境跑一遍回归，重点验证登录、文件上传、工作流这几个核心模块。

如果业务太老旧，升级成本太高，至少也要把官方发布的安全补丁、组件依赖更新打到生产环境，这一步能做到的话，一键工具的有效性会大打折扣。

4.2 代码层面的防注入加固

除了框架升级，存量代码也值得过一遍。搜代码里所有手写SQL的地方，看有没有直接用字符串拼接的，全部改成MyBatis或JPA的预编译写法。

MyBatis里最安全的写法是#{}：

<select id="getUserById" resultType="User"> SELECT * FROM user WHERE id = #{id} </select>

注意${}是字符串替换，虽然业务上偶尔要用，但绝不能放在和外部输入直接接触的地方。如果有必须用动态排序字段的场景，一定要做白名单映射，不能把原字段名直接拼进去。

4.3 文件上传安全校验

文件上传这块，我分享一套我实战验证过的完整策略：

六层全部到位，基本断绝了上传即执行的路。哪怕攻击者绕过其中一两层，后续的存储隔离和访问鉴权一样能兜住。

4.4 访问控制与会话加固

接口鉴权不能只依赖前端路由。后端所有接口必须纳入统一的认证过滤器，凡是没有登录态的一律拒绝。JeecgBoot的Shiro配置要检查两点：匿名URL列表是否收得足够小、是否覆盖了所有静态资源和登录接口；权限拦截器是否对所有/**路径生效。

另外建议强制开启两步验证，至少管理员账号要开。会话超时时间设置短一点，比如30分钟无操作自动失效，能降低会话劫持的风险。

4.5 WAF规则与运行时防护

如果业务暂时不能停，可以考虑先上WAF做临时止血。在Nginx层加规则，拦截常见的攻击特征：

location / { if ($request_uri ~* "(\.\./|\.\.\\)") { return 403; } if ($request_uri ~* "(union.*select|insert.*into|update.*set)") { return 403; } if ($request_uri ~* "(\.jsp|\.jspx|\.php)[^a-zA-Z]") { return 403; } }

注意这套规则只能挡低水平的扫描攻击，对绕过了编码、分块传输的流量可能会失效，所以它只是临时止血，不能替代代码修复。有条件的话，上线RASP（运行时应用自保护）对Java应用做函数级防护效果更好，它直接监控危险函数的调用链条，即使攻击流量进来了，真正执行不到有风险的那一步就被掐断了。

5. 实例复盘：一次针对JeecgBoot的攻击推演

5.1 目标环境特征

为了验证防御思路，我在内网搭了一套模拟环境来推演，配置是这样的：JeecgBoot老版本、默认数据库口令未修改、文件上传目录在Web根下、后台接口未做统一鉴权。

这套环境在现实里很有代表性，尤其是“默认口令+接口未鉴权”这两项，几乎是一键工具的首选目标。

5.2 攻击路径推演

在防御视角下，攻击者的路径大概是这样的：

第一步先做指纹识别，确认对方是JeecgBoot。这一步靠前端特征就能完成，基本绕不开。

第二步是路径扫描，用字典把常见上传接口、导出接口、后台接口全跑一遍。老版本如果存在未授权接口，这里就暴露出来了。

第三步通过上传接口放置一个解析脚本。由于上传目录就在Web根下，文件落盘的同时就获得了解释执行能力。此时工具的主流程就完成了，剩下的都是权限维持的事。

5.3 防守对抗记录

我针对这条路径做了三层防守验证：

第一层，修复上传问题，把存储目录移到Web根之外，上传文件不再可执行。攻击者的文件落盘了，但访问路径解析不到，直接断掉链路。

第二层，给所有接口加了统一鉴权过滤器，未登录请求一律302到登录页。路径扫描失去了意义，没有有效会话的请求全被拦截。

第三层，在Nginx加了访问频率限制，单IP一秒内超过20个请求直接封禁5分钟，把扫描器的探测效率打了下来。

实测下来，同样的工具再打这套加固后的环境，连入口都找不到。这再次印证了一个观点：一键工具再猛，打的还是人的懒惰。

6. 常见问题与排查技巧实录

6.1 升级后业务功能不兼容怎么办

有同学问过我，框架升级后之前的自定义功能跑不起来，怎么处理。

升级报错多数集中在SQL语法、老接口路径变更、依赖包冲突。建议先逐个模块回归测试，先跑登录、再跑菜单权限、再跑工作流，按模块记录报错。SQL报错的优先看新的框架版本是不是启用了更严格的SQL模式，把旧SQL里的隐式转换、非标准写法改掉。依赖冲突的用依赖树分析工具排查，找到重复的类库版本，统一归到新版路径下。

6.2 服务器不能重启，如何临时止血

生产环境不敢重启、不敢升级，又担心被打穿，这种情况我遇到不少。临时的思路是先把网络层挡住，在防火墙只开放业务必需的端口，把后台管理端口限制到内部IP访问；然后在WAF层把上传接口、导出接口的限速调成最低；最后把数据库账号临时改成强密码。

这套操作能显著降低暴露面，但只解决燃眉之急，治标不治本。业务窗口期一到，还是要把代码和框架补丁补上。

6.3 如何确认漏洞真的被堵住了

加固之后要验证效果，不然心里没底。验证分两步。

第一步是回测，用原来的工具和测试用例再扫一遍加固后的环境，确认打不进去。第二步是复查日志，观察一段时间内有没有新的攻击探测记录，看有没有人还在反复尝试旧路径。

如果发现某个路径还在被高频扫描，说明这条路径可能被漏了，赶紧追查对应的接口和过滤器配置。安全工作是动态的，没有“改一次就一劳永逸”这回事。

6.4 日志量太大，怎么快速定位问题

JeecgBoot的日志默认打得比较多，杂音也大。我建议用关键字筛，优先看error、exception、unauthorized、upload，把这四类单独拎出来，再结合时间轴去看。如果某个时间点系统异常增多，说明大概率有人在探测。

有条件的话，把日志接入集中式日志平台，按字段建索引，查询效率会高很多。手动翻日志只适合临时排查，不适合长期监控。

7. 我的一点实际体会

跟Jeecg_Tools对抗了这一轮，我的感受是：这类工具的杀伤力不在于技术多厉害，而在于它把“利用”的门槛降到了一个完全不需要理解的级别。真正挡不住攻击的系统，往往不是缺高深的安全架构，而是连最基础的补丁、密码、鉴权三件事都没做好。

我个人建议所有还在跑JeecgBoot的团队，今天先做三件事：

第一，确认当前版本号和官方最新版本的差距，如果差距超过两个大版本，立刻安排升级计划。第二，检查默认密码，尤其是后台管理员和数据库连接账号，全部改成无规律强密码。第三，梳理所有对外提供的接口，把没有鉴权的接口列出来，限期加上认证。

这三个动作做完，Jeecg_Tools对你的系统基本就废了。后续再做代码层面的防注入和上传加固，日常巡检和日志监控跟上，JeecgBoot依然可以跑得很稳。安全没有终点，每一轮攻击工具的爆火，其实都是在提醒我们把基本功打牢。