Spring Boot导出Excel时SQL排序注入点修复方法

先说一个核心判断：在Spring Boot导出Excel时，如果用户能指定排序字段，那ORDER BY后面的内容绝对不能参数化——JDBC和所有主流ORM都不支持对排序字段做参数绑定。直接拼接字符串等于把SQL解析权拱手交给攻击者，这可不是危言耸听。

ORDER BY 字段不能参数化，必须白名单校验

假设导出接口允许用户传?sort_field=created_at&sort_order=desc，常见的错误是试图用正则过滤或转义单引号，但攻击者总能绕过：sort_field=1; DROP TABLE users--、sort_field=(SELECT password FROM admins)、sort_field=`status` ASC, (SELECT 1) -- 都能成功执行。所以唯一可靠的手段就是白名单硬编码。

• 白名单必须硬编码，比如 private static final Set ALLOWED_SORT_FIELDS = Set.of("id", "name", "email", "created_at", "amount");
• 校验要严格区分大小写：PostgreSQL默认区分，MySQL默认不区分；建议统一用小写存储白名单，输入调用.toLowerCase()后再比对
• 排序方向（ASC/DESC）也要单独白名单校验，比如Set.of("ASC", "DESC")，禁止透传任意字符串
• 如果业务支持多字段排序（如sort_field=name,created_at），必须拆分后逐个校验，任一不匹配就拒绝

MyBatis-Plus 动态排序的正确写法

用@Select注解或XML写原生SQL时，${}是危险的（直接替换），而#{}对ORDER BY无效（会加引号导致语法错误）。所以别指望MyBatis的占位符能蒙混过关。正确做法是：在Service层完成白名单校验，再拼接安全的SQL片段。

String sortField = request.getParameter("sort_field");
String sortOrder = request.getParameter("sort_order");
if (!ALLOWED_SORT_FIELDS.contains(sortField.toLowerCase()) ||
    !ALLOWED_SORT_ORDERS.contains(sortOrder.toUpperCase())) {
    throw new IllegalArgumentException("Invalid sort parameter");
}
String safeOrderBy = String.format("%s %s", sortField, sortOrder);
// 再传入 MyBatis 的 ${}，此时已无风险

• XML中写成ORDER BY ${safeOrderBy}，但前提是safeOrderBy已经是校验后的纯字母+空格+ASC/DESC
• 避免在Mapper接口方法签名里直接接收@Param("sortField") String sortField并传给${}——校验必须在进入DAO层前完成
• 如果用QueryWrapper，不要写wrapper.orderBy(true, true, sortField)，因为sortField未校验；应先校验，再调用wrapper.orderByAsc("id").orderByDesc("created_at")等固定链式调用

Spring Data JPA 的排序注入风险点

Sort.by("user_input")看着挺安全的，但实际很危险——它底层仍然把字符串拼进ORDER BY子句，且不做白名单检查。传入new Sort(Sort.Direction.ASC, "name; DROP TABLE users--")就能触发注入。JPA的Pageable构造函数同样不校验字段名，PageRequest.of(0, 10, Sort.by("status"))中的"status"必须来自可信源。

• 禁止直接将request.getParameter("sort")塞进Sort.by()
• 正确做法：解析参数 → 白名单比对 → 映射为预定义的Sort实例，比如Map.of("created_at", Sort.by(Sort.Direction.DESC, "created_at"))
• 若需支持多字段，用Sort.by(Sort.Order.asc("name"), Sort.Order.desc("created_at"))，而不是拼字符串
• 注意Sort.Order构造器接受字段名但不校验，所以映射逻辑必须前置

导出接口中容易被忽略的别名与反引号陷阱

有些导出需求允许用户自定义列别名，比如SELECT name AS `Full Name`, email AS `Contact Email` FROM users。反引号内的内容如果来自用户输入，就可能逃逸并闭合引号，插入恶意SQL。比如用户传alias=`status` ASC, (SELECT 1)--，拼进去变成SELECT status AS `status` ASC, (SELECT 1)--` FROM users，直接破坏语法甚至执行子查询。

• 别名必须走第二套白名单，或者干脆禁止用户自定义别名，统一用代码内建的中文映射（如Map.of("name", "姓名", "email", "邮箱")）
• 如果必须支持带空格别名，只允许用下划线替代空格（full_name），并拒绝任何反引号、双引号、单引号字符
• 校验逻辑应放在Controller层，早于任何SQL拼接动作；不要依赖前端传来的“看起来合法”的字符串
• 特别注意MySQL的标识符引号是反引号，PostgreSQL是双引号，SQL Server是方括号——白名单校验不解决跨库问题，统一用小写字母+下划线是最稳妥的兼容方案

说到底，真正的难点不在于写校验逻辑，而在于确认所有导出入口——包括后台管理页、API文档测试框、Swagger UI、Postman收藏夹里的旧请求——都经过同一套白名单校验。漏掉一个，就等于整条防线失效。