防止SQL注入的DAO层参数绑定规范

绝大多数开发者都知道SQL注入的危害，但在实际编码中，DAO层的参数绑定依然存在大量模糊地带。问题的根源不在于“不知道”，而在于“以为安全”的侥幸心理。比如很多人认为只要用了MyBatis的#{}就万事大吉，却忽略了动态表名、排序字段、IN查询等场景下，参数绑定的规则完全不同。SQL注入的本质是用户输入的数据被数据库引擎当作SQL指令的一部分执行，而DAO层参数绑定的核心任务就是彻底切断这种可能性。要做到这一点，必须建立一套严格的规范，覆盖所有SQL拼接场景，不留任何死角。

预编译语句（PreparedStatement）是防御SQL注入最根本的手段。它的工作机制是先向数据库发送SQL模板，再单独传递参数值，参数值永远不会参与SQL语法解析。这意味着任何企图通过参数注入恶意代码的行为都会失效，因为数据库已经把SQL结构固定下来了。在Java生态中，JdbcTemplate、MyBatis、Hibernate等框架都封装了预编译功能，但前提是必须正确使用占位符语法。

MyBatis中#{}和${}的区别是血泪教训换来的常识。#{}会生成预编译占位符，参数值被安全地设置进去；${}则是直接字符串替换，等同于裸拼SQL。规范必须明确：所有用户可控的输入，一律使用#{}。这条规则没有例外。即便某个参数看起来“只从内部系统传入”，只要它经过网络、来自前端、存储在数据库后被读出再拼接，就必须视为不可信数据。很多二次注入正是利用了“内部数据可信”的错觉。

JPA和Hibernate用户同样面临陷阱。JPQL中可以使用命名参数或位置参数，这些是安全的。但原生SQL查询中的字符串拼接，以及Criteria API中动态构建条件时，如果直接拼接用户输入到字段名或操作符中，同样会引入注入风险。规范必须覆盖ORM框架的所有查询方式，不能因为用了ORM就放松警惕。

动态表名、动态列名、动态排序字段是DAO层参数绑定的三大雷区。预编译占位符只能绑定值，不能绑定标识符（如表名、列名）。当业务需要动态切换表名或排序字段时，开发者往往被迫使用字符串拼接，此时如果没有白名单校验，SQL注入就不可避免。

规范要求：任何动态标识符必须经过严格的白名单验证。具体做法是维护一个允许的标识符集合，将用户输入与该集合进行匹配，匹配不通过则拒绝执行。代码示例如下：

private static final Set<String> ALLOWED_COLUMNS = Set.of("id", "username", "email", "create_time");
private static final Set<String> ALLOWED_DIRECTIONS = Set.of("ASC", "DESC");

public List<User> getUsersByOrder(String orderBy, String sortDirection) {
    if (orderBy == null || !ALLOWED_COLUMNS.contains(orderBy)) {
        throw new IllegalArgumentException("Invalid column: " + orderBy);
    }
    if (sortDirection == null || !ALLOWED_DIRECTIONS.contains(sortDirection.toUpperCase())) {
        throw new IllegalArgumentException("Invalid sort direction: " + sortDirection);
    }
    return mapper.getUsersByOrder(orderBy, sortDirection.toUpperCase());
}

注意，白名单验证必须在DAO层入口处完成，不能依赖上层调用方保证数据合法性。DAO层作为数据访问的最后关卡，必须对自身接收的所有参数负责。即使上层已经做了校验，DAO层的白名单依然不能省略，这是纵深防御原则的体现。

SQL中IN子句的参数数量往往不固定，很多开发者图方便直接用字符串拼接，这是极其危险的做法。正确方案是使用MyBatis的foreach标签动态生成占位符，或者使用JdbcTemplate的NamedParameterJdbcTemplate配合数组参数。

MyBatis处理IN查询的安全写法：

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

foreach标签会为每个元素生成一个预编译占位符，参数值通过#{}安全绑定。如果使用JdbcTemplate，可以利用NamedParameterJdbcTemplate将List参数映射到命名参数：

MapSqlParameterSource params = new MapSqlParameterSource();
params.addValue("ids", Arrays.asList(1, 2, 3));
List<User> users = namedParameterJdbcTemplate.query(
    "SELECT * FROM users WHERE id IN (:ids)", 
    params, 
    new UserRowMapper()
);

Spring JDBC会自动将集合参数展开为多个占位符，确保安全。规范必须禁止任何形式的IN子句字符串拼接，包括使用String.join或StringBuilder手动构造参数列表。

LIKE查询需要处理通配符%和_，这些字符在LIKE语境下有特殊含义。如果用户输入本身包含这些字符，直接拼入LIKE模式可能导致意外匹配，甚至在某些数据库中存在注入变种风险。规范要求：LIKE查询必须使用预编译占位符绑定参数，通配符在参数值中拼接而非SQL中拼接，同时对用户输入中的通配符进行转义。

正确做法是在Java代码中处理通配符，然后将完整模式作为参数绑定：

String keyword = userInput.replace("\\", "\\\\")
                         .replace("%", "\\%")
                         .replace("_", "\\_");
String pattern = "%" + keyword + "%";
List<User> users = mapper.findByKeyword(pattern);

SQL中只需使用#{}绑定pattern参数，同时在LIKE后面添加ESCAPE子句指定转义字符：

SELECT * FROM users WHERE username LIKE #{pattern} ESCAPE '\\'

这样既保证了安全，又正确处理了用户输入中的特殊字符。很多开发者只记得用#{}绑定，却忘了转义通配符，导致功能缺陷或潜在风险，规范必须明确这两步操作缺一不可。

批量插入或更新时，循环拼接SQL语句是常见的不安全做法。MyBatis的foreach标签同样适用于批量操作，但需要注意参数数量上限。不同数据库对SQL语句中的占位符数量有限制，Oracle是1000个，MySQL的max_prepared_stmt_count参数也有约束。当批量数据量较大时，应分批执行，每批大小控制在数据库限制以内。

规范要求批量操作必须使用框架提供的批处理机制，禁止手动循环拼接VALUES子句。MyBatis示例：

<insert id="batchInsert">
    INSERT INTO users (username, email) VALUES
    <foreach item="user" collection="userList" separator=",">
        (#{user.username}, #{user.email})
    </foreach>
</insert>

如果数据量超过500条，应使用ExecutorType.BATCH模式分批提交，或调用SqlSession的flushStatements方法定期刷新。规范还需明确：批量操作的参数集合不能直接从用户请求中获取而不做数量限制，防止攻击者通过构造超大集合进行拒绝服务攻击。

调用存储过程时，开发者容易忽视OUT参数和INOUT参数的安全风险。虽然存储过程本身可能已经做了参数化处理，但DAO层的调用方式仍然需要规范。使用CallableStatement时，所有IN参数必须通过setXxx方法设置，不能拼接到调用SQL中。MyBatis调用存储过程时，必须使用JDBC标准占位符语法，不能使用${}拼接参数。

此外，存储过程内部如果使用了动态SQL拼接，DAO层无法直接控制，这要求DBA和开发团队协作，确保存储过程内部也遵循参数绑定规范。DAO层的职责是保证调用方式安全，并对存储过程的输入参数进行校验，不能假设存储过程内部已经万无一失。

在复杂项目中，可能同时使用MyBatis、JPA和原生JDBC。规范必须覆盖所有数据访问方式，不能留下死角。原生JDBC的Statement对象绝对禁止使用，只能使用PreparedStatement。即便只是执行一条看似无害的DDL语句，只要包含用户输入，就必须参数化。对于确实无法参数化的DDL场景（如动态创建表），必须使用白名单验证标识符，且这类操作应限制在管理后台并记录审计日志。

规范还应明确代码审查要点：任何包含字符串拼接的SQL相关代码，审查者必须要求开发者证明其安全性。如果无法证明，必须改为参数绑定方式。静态代码分析工具（如SonarQube、Fortify）的SQL注入规则应开启并纳入CI流水线，违规代码不得合并。

数据库驱动在设置参数时会进行类型映射，但类型不匹配可能导致隐式转换，极端情况下可能被利用。规范要求DAO层参数必须使用明确的Java类型，避免将数字以字符串形式传递。MyBatis中应指定jdbcType，特别是传入null值时，必须声明jdbcType，否则驱动可能无法正确推断类型，导致SQL执行异常或被利用。

示例：

#{userId, jdbcType=INTEGER}
#{username, jdbcType=VARCHAR}

对于日期类型，应使用java.time包下的LocalDate、LocalDateTime等，避免使用java.util.Date的模糊时区。类型明确不仅提升安全性，也减少数据库执行计划缓存失效的问题。

参数绑定规范需要与输入校验规范衔接。DAO层不负责业务规则校验，但必须进行安全校验。具体来说，DAO层应校验参数的非空性（如果数据库字段不允许NULL）、类型正确性、长度限制（防止超出数据库字段长度）、以及标识符的白名单匹配。业务逻辑校验（如邮箱格式、用户名唯一性）应由Service层负责。这种分层校验机制确保即使Service层校验被绕过，DAO层仍能守住安全底线。

规范落地需要配套的代码模板和检查清单。每个DAO方法应遵循统一结构：参数接收、安全校验、参数绑定、执行查询、结果返回。安全校验代码应提取为私有方法或工具类，避免重复实现导致的不一致。团队应定期进行安全编码培训，重点剖析真实注入案例，让规范从文档变成肌肉记忆。

DAO层参数绑定规范不是一纸空文，而是每个数据访问方法都必须遵守的硬约束。从预编译占位符的强制使用，到动态标识符的白名单验证，从IN查询的foreach展开，到LIKE查询的转义处理，每个环节都有明确的技术要求和代码范例。规范的生命力在于执行，代码审查、静态分析、自动化测试三重保障缺一不可。只有将安全要求嵌入日常开发流程，才能真正杜绝SQL注入这类古老却依然猖獗的漏洞。