Mybatis SQL注入防护全攻略与最佳实践

1. Mybatis框架与SQL注入风险全景解析

作为Java生态中最主流的ORM框架之一，Mybatis凭借其灵活的SQL编写方式和优秀的性能表现，已经成为企业级应用开发的标准配置。但正是这种"半自动化"的特性，使得开发者在享受SQL编写自由度的同时，也面临着严峻的SQL注入风险。我见过太多团队因为忽视这个问题，导致数据库被拖库、用户信息泄露等安全事故。

SQL注入本质上是一种通过构造特殊输入参数，改变原始SQL语义的攻击方式。在传统的JDBC编程中，字符串拼接是最典型的注入漏洞来源。而Mybatis虽然提供了#{}和${}两种参数注入方式，但很多初学者往往分不清它们的区别，错误使用${}导致注入漏洞。更棘手的是，即使正确使用了#{}，在某些特殊场景下（如动态表名、排序字段等）仍然可能被迫使用${}，这就需要我们掌握更全面的防护策略。

2. Mybatis参数注入机制深度剖析

2.1 #{}与${}的本质区别

先看一个典型的安全案例：

java复制@Select("SELECT * FROM users WHERE username = #{name} AND password = #{pass}")
User login(@Param("name") String name, @Param("pass") String pass);

这里的#{}会被Mybatis预处理为参数化查询，等价于JDBC的PreparedStatement，输入参数会被当作纯数据处理，不会改变SQL结构。

而危险的使用方式：

java复制@Select("SELECT * FROM users WHERE username = '${name}'")
User findUser(@Param("name") String name);

当传入name = "admin' OR '1'='1"时，最终执行的SQL变为：

sql复制SELECT * FROM users WHERE username = 'admin' OR '1'='1'

这将返回所有用户数据，造成严重的信息泄露。

2.2 动态SQL中的潜在风险

Mybatis的动态SQL功能虽然强大，但也隐藏着注入隐患。比如常见的<if>条件判断：

xml复制<select id="searchUsers" resultType="User">
  SELECT * FROM users
  WHERE 1=1
  <if test="name != null">
    AND username LIKE '%${name}%'
  </if>
</select>

这里的LIKE查询如果使用${}拼接，攻击者可以构造特殊输入破坏查询逻辑。正确的做法应该是：

xml复制<if test="name != null">
  AND username LIKE CONCAT('%', #{name}, '%')
</if>

3. 全场景防护方案与实战技巧

3.1 必须使用${}的场景与解决方案

有些场景确实无法避免使用${}，比如动态表名：

java复制@Select("SELECT * FROM ${tableName} WHERE id = #{id}")
User findById(@Param("tableName") String tableName, @Param("id") Long id);

针对这种情况，我总结出三层防护策略：

1. 白名单校验：对表名参数进行严格校验

java复制private static final Set<String> ALLOWED_TABLES = Set.of("users", "products");

public User findByIdSafe(String tableName, Long id) {
    if (!ALLOWED_TABLES.contains(tableName)) {
        throw new IllegalArgumentException("Invalid table name");
    }
    return mapper.findById(tableName, id);
}

2. 正则过滤：移除所有非字母数字下划线字符

java复制tableName = tableName.replaceAll("[^a-zA-Z0-9_]", "");

3. 数据库权限隔离：应用账号只拥有必要表的CRUD权限

3.2 Mybatis插件实现自动化防护

我们可以通过自定义插件，在运行时拦截和检查所有SQL：

java复制@Intercepts({
    @Signature(type= StatementHandler.class, 
              method="prepare", 
              args={Connection.class, Integer.class})
})
public class SqlInjectionInterceptor implements Interceptor {
    @Override
    public Object intercept(Invocation invocation) throws Throwable {
        StatementHandler handler = (StatementHandler) invocation.getTarget();
        BoundSql boundSql = handler.getBoundSql();
        
        // 检测SQL中的${}使用
        if (boundSql.getSql().contains("${")) {
            log.warn("Potential SQL injection risk: " + boundSql.getSql());
            // 可以加入邮件报警等机制
        }
        
        return invocation.proceed();
    }
}

在mybatis-config.xml中配置：

xml复制<plugins>
    <plugin interceptor="com.example.SqlInjectionInterceptor"/>
</plugins>

4. 企业级最佳实践与架构设计

4.1 分层防御体系构建

在实际企业环境中，我建议建立多层次的防御：

1. 输入层：

   • 所有API参数使用JSR-303进行基础校验
   • 对字符串类型参数进行HTML/JS/SQL特殊字符转义

2. DAO层：

   • 强制代码审查，禁止直接使用${}
   • 使用MyBatis Generator生成基础CRUD代码
   • 对动态SQL进行安全扫描

3. 数据库层：

   • 配置最小权限原则
   • 开启SQL审计日志
   • 对敏感表启用数据脱敏

4.2 安全开发流程规范

我们团队制定的安全编码规范包括：

1. 静态代码扫描：

   • 在CI流程中加入SQL注入检测
   • 使用SonarQube配置自定义规则扫描${}使用

2. 单元测试要求：

   java复制@Test
   void testSqlInjection() {
       // 测试注入攻击
       assertThrows(Exception.class, () -> {
           userMapper.findByUsername("admin' --");
       });
       
       // 测试特殊字符处理
       User user = userMapper.findByUsername("normal_user");
       assertNotNull(user);
   }
   

3. 安全评审机制：

   • 所有涉及原生SQL的变更必须经过安全评审
   • 定期进行安全培训与攻防演练

5. 高级防御技巧与性能优化

5.1 预编译语句的进阶用法

即使是使用#{}，在某些复杂场景下也需要特别注意：

java复制@Select("SELECT * FROM users WHERE id IN (${ids})")
List<User> findByIds(@Param("ids") String ids);

这种IN查询的正确处理方式应该是：

方案1：使用MyBatis的动态SQL

xml复制<select id="findByIds" resultType="User">
  SELECT * FROM users
  WHERE id IN
  <foreach collection="ids" item="id" open="(" separator="," close=")">
    #{id}
  </foreach>
</select>

方案2：使用数据库特定函数（MySQL示例）

java复制@Select("SELECT * FROM users WHERE FIND_IN_SET(id, #{ids}) > 0")
List<User> findByIdsSafe(@Param("ids") String ids);

5.2 存储过程的安全调用

对于复杂业务逻辑，可以考虑使用存储过程：

java复制@Options(statementType = StatementType.CALLABLE)
@Select("{call sp_get_user_by_credentials(#{name}, #{pass})}")
User loginByProcedure(@Param("name") String name, @Param("pass") String pass);

存储过程的优势在于：

1. SQL逻辑完全在数据库端控制
2. 应用层只传递参数，不拼接SQL
3. 可以进行更精细的权限控制

6. 实战演练：从漏洞发现到修复

让我们通过一个完整案例来演示安全审计过程：

漏洞代码：

java复制@Select("SELECT * FROM products WHERE name LIKE '%${keyword}%' " +
        "ORDER BY ${sortField} ${sortOrder}")
List<Product> searchProducts(@Param("keyword") String keyword,
                           @Param("sortField") String sortField,
                           @Param("sortOrder") String sortOrder);

攻击方式：

code复制keyword = test'; DROP TABLE products; --
sortField = (SELECT CASE WHEN (SELECT current_user)='dbadmin' THEN name ELSE id END)
sortOrder = DESC

修复方案：

1. 使用#{}处理搜索词：

java复制@Select("SELECT * FROM products WHERE name LIKE CONCAT('%', #{keyword}, '%')")
List<Product> searchProductsSafe(@Param("keyword") String keyword);

2. 排序字段白名单校验：

java复制private String validateSortField(String field) {
    return Arrays.asList("name", "price", "create_time").contains(field) ? field : "id";
}

private String validateSortOrder(String order) {
    return "DESC".equalsIgnoreCase(order) ? "DESC" : "ASC";
}

3. 最终安全版本：

java复制@SelectProvider(type = ProductSqlBuilder.class, method = "buildSearchSql")
List<Product> searchProductsSafe(@Param("keyword") String keyword,
                               @Param("sortField") String sortField,
                               @Param("sortOrder") String sortOrder);

// 在SqlBuilder中实现安全控制
class ProductSqlBuilder {
    public String buildSearchSql(Map<String, Object> params) {
        String keyword = (String) params.get("keyword");
        String sortField = validateSortField((String) params.get("sortField"));
        String sortOrder = validateSortOrder((String) params.get("sortOrder"));
        
        return new SQL() {{
            SELECT("*");
            FROM("products");
            if (StringUtils.isNotBlank(keyword)) {
                WHERE("name LIKE CONCAT('%', #{keyword}, '%')");
            }
            ORDER_BY(sortField + " " + sortOrder);
        }}.toString();
    }
}

7. 监控与应急响应机制

7.1 SQL注入攻击识别

在生产环境中，我们需要建立有效的监控机制：

1. 日志分析规则：

   • 检测包含--、;、'、/*等特殊字符的请求
   • 监控异常SQL执行时间（攻击常伴随全表扫描）

2. WAF规则配置：

   nginx复制location /api {
       # 阻止常见SQL注入特征
       if ($args ~* "union.*select|select.*from|insert.*into|delete.*from") {
           return 403;
       }
       proxy_pass http://app_server;
   }
   

7.2 应急响应流程

一旦发现注入攻击，应立即：

1. 隔离受影响系统
2. 分析攻击入口点
3. 回滚到安全版本
4. 审计所有类似代码
5. 重置数据库密码
6. 检查数据完整性

8. 开发者自查清单

最后分享一个我团队使用的自查表，每个Mybatis方法都需要经过这些检查：

1. [ ] 是否完全避免了${}的使用？
2. [ ] 动态表名/列名是否经过白名单校验？
3. [ ] LIKE查询是否使用CONCAT函数？
4. [ ] IN查询是否使用处理？
5. [ ] 排序参数是否经过校验？
6. [ ] 是否对批量操作做了数量限制？
7. [ ] 是否配置了SQL拦截插件？
8. [ ] 单元测试是否包含注入测试用例？

记住，安全不是一次性的工作，而是需要持续关注的系统工程。每次代码变更、每个新功能上线，都应该把SQL注入防护作为首要考虑因素。