ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

首页/资讯中心/资讯详情

JEECG-BOOT SQL注入漏洞深度解析与MyBatis-Plus安全实践

发布时间：2026/8/13 6:34:05 拓冰企业网站定制
JEECG-BOOT SQL注入漏洞深度解析与MyBatis-Plus安全实践

1. 项目概述：从一次安全告警说起

那天下午，我正在梳理线上系统的监控日志，一个来自安全扫描平台的“高危”告警突然弹了出来，标题赫然写着“JEECG-BOOT SQL注入漏洞”。相信很多使用过JEECG-BOOT这个国内流行的低代码开发平台的朋友，对这个词条都不会陌生。它不是一个新问题，但却是每个项目在快速迭代、功能堆叠过程中，最容易忽视和反复踩坑的“老大难”。我当时负责的系统，正是一个基于JEECG-BOOT 2.x版本快速搭建的后台管理系统，告警指向的是一个看似普通的查询接口。这不仅仅是修复一个漏洞那么简单，它背后牵扯到的是对低代码平台安全机制的深度理解、对MyBatis框架使用规范的重新审视，以及如何在“快速开发”与“安全稳定”之间找到平衡点。今天，我就把这次从漏洞发现、原理分析、到彻底修复和建立防线的完整过程，以及沉淀下来的实战经验，毫无保留地分享给大家。无论你是JEECG-BOOT的使用者、维护者，还是任何使用MyBatis-plus进行开发的Java后端工程师，这篇文章都能帮你建立起一道坚固的SQL注入防火墙。

2. 漏洞原理深度剖析：低代码平台的“阿喀琉斯之踵”

要解决问题，必须先透彻理解问题。JEECG-BOOT框架本身在快速生成CRUD代码方面非常高效，但它生成的一些代码模式，尤其是在处理动态查询条件时，如果开发者安全意识不足或使用不当，就极易引入SQL注入风险。

2.1 漏洞产生的典型场景

在我遇到的案例中，以及社区反馈的常见问题里，漏洞通常集中在以下几个场景：

  1. 自定义SQL片段中的${}误用：这是最经典的错误。JEECG-BOOT的代码生成器或开发者手动编写XML映射文件时，为了图方便，在ORDER BY、GROUP BY、表名、字段名等动态部分直接使用了${column}进行字符串拼接，而非安全的#{value}参数化绑定。

    <!-- 危险示例：直接拼接 --> <select id="selectUser" resultType="User"> SELECT * FROM sys_user WHERE 1=1 <if test="orderBy != null and orderBy != ''"> ORDER BY ${orderBy} <!-- 攻击者可传入`id; DROP TABLE sys_user --` --> </if> </select>

  2. Wrapper条件构造器的模糊查询滥用：MyBatis-Plus的QueryWrapper或LambdaQueryWrapper提供了like、likeLeft、likeRight等方法。如果前端传入的参数未经处理直接拼接，也可能导致问题。虽然MP本身对eq、ne等条件做了参数化处理，但某些复杂动态拼接场景下，开发者若手动拼接SQL片段到Wrapper中，风险依然存在。

    // 潜在风险示例：如果`username`来自不可信的前端输入 String userInput = request.getParameter("keyWord") + "%"; queryWrapper.like("username", userInput); // 如果MP版本存在缺陷或使用特定方法，可能有问题 // 更危险的是手动拼接： queryWrapper.apply("date_format(create_time,'%Y-%m-%d') = '" + userInput + "'"); // 绝对禁止！

  3. “Online表单”或“报表配置”等动态查询功能：JEECG-BOOT引以为傲的在线开发功能，允许通过界面配置查询字段和条件。这些配置最终会动态生成SQL语句。如果该功能的实现没有对用户输入的字段名、条件值做严格的过滤和白名单校验，那么这里就是一个巨大的注入入口。

  4. 多租户数据隔离绕过：在SAAS系统中，JEECG-BOOT通常使用tenant_id进行数据隔离。如果SQL注入漏洞发生在查询条件中，攻击者有可能精心构造Payload，绕过tenant_id的限制，访问或篡改其他租户的数据，造成严重的数据越权。

2.2 为什么低代码平台更容易中招？

这与其设计初衷有关。低代码平台的核心是“通过少量代码或配置快速生成功能”，它抽象了底层数据库操作，提供了大量“灵活”的配置项。这种“灵活性”如果缺乏安全边界的约束，就变成了“随意性”。平台开发者可能更关注功能的实现和易用性，而将安全责任 implicitly 转移给了使用平台的业务开发者。但业务开发者又可能过于依赖平台的“智能”，忽视了底层可能存在的风险，从而形成了安全盲区。

注意：不要认为使用了MyBatis-Plus或JEECG-BOOT就高枕无忧。任何ORM框架都只是工具，是否安全取决于使用工具的方式。将用户输入直接拼接成SQL语句的一部分，在任何框架下都是极度危险的。

3. 系统化解决方案：从紧急止血到长治久安

面对SQL注入漏洞，切忌“头痛医头，脚痛医脚”。我采取的是一种分层递进的修复策略，从最直接的漏洞点修复，到代码规范建设，最后到平台级防护。

3.1 第一步：精准定位与紧急修复

首先，根据安全扫描报告提供的URL和参数，在代码中定位到具体的Mapper接口及XML文件或Service实现类。

场景一：修复XML中的${}注入对于ORDER BY这类确实需要动态字段的场景，放弃直接使用${}。改为使用安全的“白名单”映射方式。

<!-- 修复后示例 --> <select id="selectUser" resultType="User"> SELECT * FROM sys_user WHERE 1=1 <if test="orderBy != null and orderBy != ''"> ORDER BY <choose> <when test="orderBy == 'createTime'">create_time</when> <when test="orderBy == 'username'">username</when> <!-- 只允许列出的几个字段 --> <otherwise>id</otherwise> <!-- 默认排序 --> </choose> </if> </select>

如果排序字段非常多，维护白名单太麻烦，可以建立一个安全的字段映射枚举类，并在Java代码中进行校验，确保传入的字符串只能是枚举值之一，再将枚举值传递给Mapper。

场景二：修复Wrapper中的不安全拼接立即审查代码中所有使用queryWrapper.apply()、queryWrapper.last()以及字符串拼接构造条件的地方。apply和last可以直接执行SQL片段，必须禁止任何用户输入直接传入这些方法。

// 错误示例 String unsafeDate = request.getParameter("date"); // 假设传入 `'2024-01-01' OR 1=1 --` wrapper.apply("create_time > " + unsafeDate); // 正确做法：使用参数化 wrapper.apply("create_time > {0}", safeDate); // MyBatis-Plus的apply支持预编译占位符 // 或者更优：使用ge, le等方法 wrapper.ge("create_time", safeDate);

对于模糊查询，确保传入like方法的参数本身不包含通配符%和_。如果需要，应在业务逻辑层显式添加，并考虑对参数中的这些特殊字符进行转义（如果业务允许它们作为普通字符）。

场景三：修复Online开发等动态查询这是最复杂的一环。需要审查jeecg-boot-module-system中关于动态查询生成的源码，特别是QueryGenerator类和相关SQL解析逻辑。核心思路是：对字段名（Column）进行严格的白名单校验（可基于数据库元信息或预定义的实体类字段），对条件值（Value）进行参数化处理。可能需要重写部分平台代码。一个临时的加固方案是在拦截器或过滤器中，对特定路径的请求参数进行严格的SQL关键词过滤（但这不是根本解决方案，容易误伤和绕过）。

3.2 第二步：引入持久层安全编码规范

紧急修复后，必须建立团队规范，防止类似问题再次发生。

  1. 强制代码审查规则：

    • 禁止规则：在代码审查中，一看到XML中出现${}（除了${ew.sqlSegment}等MP内部安全使用外），立即打回。一看到Java代码中出现字符串拼接+与SQL片段（如表名、字段名、条件）的结合，立即打回。
    • 白名单规则：所有动态排序、分组、字段选择，必须通过白名单（枚举、常量池、配置文件）映射。

  2. MyBatis-Plus Wrapper使用公约：

    • 优先使用LambdaQueryWrapper，利用方法引用（Entity::getField）避免字段名拼写错误和潜在注入。
    • apply方法仅用于数据库函数调用等绝对安全的静态片段，且必须使用预编译占位符{0}、{1}。
    • 绝对禁止使用last方法拼接LIMIT以外的语句（LIMIT值也应是数字参数）。

  3. 输入验证与净化：

    • 在Controller层或独立的校验层，对所有查询参数进行类型、长度、格式的校验。
    • 对于字符串参数，根据业务上下文，决定是否过滤或转义SQL元字符（'、"、--、#、/*、*/等）。但记住，参数化查询是根本，过滤只是辅助防线。

3.3 第三步：部署运行时防护与监控

代码规范是人来执行的，总有疏忽的时候。因此需要机器（工具）来提供最后一道防线。

  1. 启用SQL防火墙：使用像Druid连接池自带的WallFilter。它能基于语义分析，在运行时拦截疑似注入的SQL执行。在application.yml中配置：

    spring: datasource: druid: filters: stat,wall wall: enabled: true config: delete-allow: false # 禁止DELETE无WHERE drop-table-allow: false # 禁止DROP TABLE

    当有注入攻击时，Druid会抛出SQLException并记录日志，阻止恶意SQL到达数据库。

  2. 部署WAF（Web应用防火墙）：在应用服务器前部署一层WAF，如ModSecurity（开源）或云厂商提供的WAF服务。它可以基于规则集，在HTTP层拦截常见的SQL注入攻击Pattern，为应用提供一个额外的保护层。

  3. 加强日志审计：确保所有数据库操作日志（尤其是慢查询日志、Druid的StatView日志）被完整收集并接入日志平台（如ELK）。对日志中的异常SQL模式（如大量OR 1=1、UNION SELECT）设置告警规则，便于安全团队及时发现正在进行的攻击尝试。

4. 实战演练：对一个真实漏洞的修复全记录

为了让思路更清晰，我以最初触发告警的那个接口为例，展示完整的修复流程。假设接口为/sys/user/list，接收参数orderField和orderType进行动态排序。

4.1 漏洞代码还原

// Controller @GetMapping("/list") public Result<?> queryPageList(User user, @RequestParam(name="orderField", defaultValue="") String orderField, @RequestParam(name="orderType", defaultValue="asc") String orderType) { // ... 其他逻辑 QueryWrapper<User> queryWrapper = QueryGenerator.initQueryWrapper(user, req.getParameterMap()); // 不安全的排序拼接 if(StringUtils.isNotBlank(orderField)){ String orderSql = orderField + " " + orderType; queryWrapper.orderBy(true, true, orderSql); // 危险！orderBy内部可能使用${} } IPage<User> pageList = userService.page(page, queryWrapper); return Result.OK(pageList); }

对应的XML中，如果QueryGenerator生成的Wrapper处理不当，或者orderBy方法最终以${}方式拼接，漏洞就产生了。

4.2 安全修复方案实施

方案A（推荐）：在Service层进行白名单校验

@Service public class UserServiceImpl extends ServiceImpl<UserMapper, User> implements IUserService { // 定义允许排序的字段白名单 private static final Set<String> ALLOWED_ORDER_FIELDS = new HashSet<>(Arrays.asList( "create_time", "update_time", "username", "realname" )); @Override public IPage<User> queryPageListWithSafeOrder(Page<User> page, QueryWrapper<User> wrapper, String orderField, String orderType) { // 1. 白名单校验 if (StringUtils.isNotBlank(orderField)) { if (!ALLOWED_ORDER_FIELDS.contains(orderField.toLowerCase())) { log.warn("非法的排序字段尝试: {}", orderField); orderField = "create_time"; // 降级为默认字段 } // 2. 校验排序类型 if (!"asc".equalsIgnoreCase(orderType) && !"desc".equalsIgnoreCase(orderType)) { orderType = "asc"; } // 3. 使用LambdaWrapper进行安全的排序 LambdaQueryWrapper<User> lambdaWrapper = wrapper.lambda(); switch (orderField.toLowerCase()) { case "create_time": lambdaWrapper.orderBy(true, "asc".equalsIgnoreCase(orderType), User::getCreateTime); break; case "username": lambdaWrapper.orderBy(true, "asc".equalsIgnoreCase(orderType), User::getUsername); break; // ... 其他字段 default: lambdaWrapper.orderByDesc(User::getCreateTime); } } else { wrapper.lambda().orderByDesc(User::getCreateTime); } return this.page(page, wrapper); } }

然后在Controller中调用这个安全的Service方法。

方案B：使用MyBatis-Plus的SqlInjection工具类（如果版本支持）较新版本的MyBatis-Plus提供了SqlInjectionChecker等工具，可以对order by等子句进行简单的注入检查。但自定义白名单仍然是控制力最强的方式。

4.3 修复验证修复后，我们进行了以下验证：

  1. 功能测试：确保正常的排序功能（如orderField=createTime&orderType=desc）工作正常。
  2. 安全测试：使用SQLMap、Burp Suite等工具，对修复后的接口重新进行注入测试。尝试传入orderField=id,(SELECT 1 FROM (SELECT SLEEP(5))a)等Payload，观察响应时间与返回结果，确认注入已失效。
  3. 代码扫描：使用SonarQube或阿里云代码安全插件，对修改后的代码进行扫描，确认不再报告SQL注入漏洞。

5. 进阶思考：在JEECG-BOOT中构建内生安全

对于基于JEECG-BOOT的长期项目，除了修复和规范，我们更应该思考如何从框架使用模式上提升整体安全性。

5.1 定制安全的代码生成器模板JEECG-BOOT的代码生成器（jeecg-boot-code-generator）是基于Velocity模板的。我们可以修改其模板文件，让生成的Controller、Service、XML默认就包含安全的排序逻辑和白名单校验，而不是生成一个危险的${orderBy}。这是“治本”的方法之一，从源头杜绝不安全代码的产生。

5.2 开发全局安全拦截器编写一个Spring MVC的HandlerInterceptor或AOP切面，针对特定命名模式的查询接口（如**/list/**,**/page/**），在请求进入Controller之前，对orderField、sort、field等常见排序参数进行全局的白名单校验和过滤。这样即使某个开发人员疏忽，也能在统一关口进行拦截。

5.3 推动框架社区修复将发现的安全问题和修复方案反馈给JEECG-BOOT开源社区。很多通用漏洞的修复，最终需要框架层面提供更安全的API或默认配置。例如，推动QueryGenerator类在解析排序参数时，默认集成一个可配置的白名单校验机制。

5.4 定期依赖安全检查使用OWASP Dependency-Check、GitHub的Dependabot或专业的SCA（软件成分分析）工具，定期检查项目依赖（包括JEECG-BOOT本身及其传递依赖）中是否存在已知的安全漏洞。及时升级框架版本，获取官方的安全补丁。

6. 总结与个人心得

处理完这次JEECG-BOOT的SQL注入漏洞，我的感触很深。低代码平台极大地提升了开发效率，但它绝不是“免检产品”。它把复杂的数据库操作封装简化，同时也把安全风险封装了起来，如果使用者不了解其底层原理和安全边界，就等于坐在一个黑盒子上开发，风险不言而喻。

我最大的体会是：安全是一个过程，而不是一个状态。没有一劳永逸的修复。它需要：

  1. 开发者具备基本的安全意识：理解SQL注入的原理，知道${}和#{}的天壤之别。
  2. 团队建立强制性的安全规范：并通过代码审查、自动化扫描工具（如Sonar）将其落地。
  3. 架构上提供多层次的防御：从参数校验、ORM框架安全使用、到SQL防火墙、WAF，层层设防。
  4. 保持对依赖的警惕：积极关注所用框架（如JEECG-BOOT、MyBatis-Plus）的安全公告，及时更新。

最后，分享一个排查小技巧：当你怀疑某个接口有SQL注入但又无法从代码直观看出时，可以开启MyBatis的完整SQL日志输出（mybatis-plus.configuration.log-impl=org.apache.ibatis.logging.stdout.StdOutImpl），观察最终执行的SQL语句。如果看到用户输入的值被直接“拼接”到了SQL语句结构中（而不是作为预编译的参数?），那么漏洞就基本坐实了。修复之路，就从那里开始。

网站建设 企业官网 运营推广
返回列表