动态参数传入场景防SQL注入校验机制

动态参数传入场景下的SQL注入，本质上是程序将用户输入的数据与SQL代码的边界搞模糊了。很多人以为加个单引号过滤就叫防护，实际上攻击者绕过的姿势远比想象中丰富。真正的校验机制必须从参数传递的那一刻就开始介入，而不是等到SQL语句拼接完成后再做补救。核心思路只有一条：让数据永远是数据，让代码永远是代码，两者绝不混淆。

无论后端用的是Java、Python、Go还是Node.js，预编译语句加参数绑定的组合，是目前最有效的防注入手段。它的原理很简单：先把SQL语句的骨架发送给数据库进行编译，再把用户输入的参数作为纯数据传递进去。数据库在编译阶段就已经确定了SQL的逻辑结构，参数再怎么包含恶意字符，也不可能改变已经编译好的执行计划。

以Java的JDBC为例，正确的写法应该是：

String sql = "SELECT id, username, email FROM users WHERE username = ? AND status = ?";
PreparedStatement pstmt = connection.prepareStatement(sql);
pstmt.setString(1, inputUsername);
pstmt.setInt(2, 1);
ResultSet rs = pstmt.executeQuery();

注意，参数占位符?绝对不能和用户输入做字符串拼接。哪怕业务需求里表名或字段名是动态的，也要用白名单映射的方式处理，而不是直接把参数拼进去。表名、字段名、排序字段这些数据库对象标识符，绝大多数数据库驱动都不支持参数化，这时候就必须在应用层做严格的白名单校验。

很多报表系统或后台管理界面，需要根据用户选择动态切换查询的表或排序字段。这种场景下，直接把前端传过来的英文字符串拼到SQL里，等于给攻击者开了后门。正确的做法是建立一个映射表，前端传的是编号或约定的标识，后端根据标识去映射表里取真实的表名或字段名。

举个例子，前端传过来一个sortField参数，值为"create_time"，后端不要直接拼。先定义一个允许的字段集合：

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

public List getUsersByOrder(String sortField, String sortDirection) {
    if (sortField == null || !ALLOWED_COLUMNS.contains(sortField)) {
        throw new IllegalArgumentException("Invalid column: " + sortField);
    }
    if (sortDirection == null || !ALLOWED_DIRECTIONS.contains(sortDirection.toUpperCase())) {
        throw new IllegalArgumentException("Invalid direction: " + sortDirection);
    }
    String sql = "SELECT id, username, email FROM users WHERE status = 1 ORDER BY " + sortField + " " + sortDirection.toUpperCase();
    // 这里的sortField和sortDirection已经经过白名单校验，可以安全拼接
    return jdbcTemplate.query(sql, new UserRowMapper());
}

这个方案的关键在于，白名单必须定义在服务端，而且要用集合的精确匹配，不能用正则或者模糊匹配。攻击者经常利用换行符、注释符、特殊编码来绕过正则，但集合的contains方法做的是精确的字符串比较，绕过的可能性为零。

很多人以为用了Hibernate、MyBatis这类ORM框架就高枕无忧了，实际上框架只在你正确使用它的时候才安全。MyBatis里用${}做字符串替换，本质上就是拼接SQL，属于高危操作。哪怕是#{}，如果用在like语句里没有处理好百分号的位置，也可能被利用。

MyBatis动态SQL的正确写法，like查询应该把百分号放在参数绑定的值里，而不是SQL模板里：

    SELECT id, username, email FROM users
    WHERE username LIKE CONCAT('%', #{keyword}, '%')
    AND status = 1

如果项目里大量使用了动态条件拼接，建议引入MyBatis的SQL注入检查插件，或者自己写个简单的拦截器，在日志中记录所有包含${}的SQL语句，定期审查。JPA的Criteria API和QueryDSL这类类型安全的查询构建器，能从编译阶段就避免字符串拼接的问题，是更安全的选择。

批量删除、批量更新这类操作，前端通常传一个ID数组过来。很多开发人员图省事，直接用字符串拼接把数组拼成逗号分隔的列表塞进SQL。比如"DELETE FROM users WHERE id IN (" + ids + ")"，这里的ids如果是字符串拼接出来的，每个元素都可能被注入。

安全的做法有两种。一种是仍然用参数化查询，动态生成对应数量的占位符：

public void deleteUsers(List ids) {
    if (ids == null || ids.isEmpty()) {
        return;
    }
    String placeholders = ids.stream().map(id -> "?").collect(Collectors.joining(","));
    String sql = "DELETE FROM users WHERE id IN (" + placeholders + ")";
    jdbcTemplate.update(sql, ids.toArray());
}

另一种是先将数组传入存储过程，在数据库端用临时表或表值参数来处理。无论哪种方式，数组里的每个元素都必须经过类型校验，Long类型就强制转Long，字符串类型就做长度和字符集限制。

有一种容易被忽视的情况：数据入库时做了转义，但出库后被拼接到另一条SQL里执行。攻击者把恶意内容存进数据库，等后续某个功能读取这条数据并动态拼接SQL时触发注入。这种二次注入的防御要点在于，永远不要信任从数据库里读出来的数据。只要是拼接到SQL里的内容，无论来源是用户直接输入还是数据库已有记录，都必须参数化处理。

另外，存储过程内部如果使用了动态SQL执行，比如MySQL的PREPARE语句或者SQL Server的sp_executesql，传入的参数同样需要严格校验。存储过程不是安全边界，它只是把SQL逻辑移到了数据库端，注入风险一点没少。

一个健壮的防注入体系，应该在多个层面设置防线。第一层是网络层的WAF，用正则规则拦截明显的注入特征，比如union select、sleep函数、信息探测函数等。但WAF很容易被编码绕过，所以只能当辅助。第二层是应用层的参数校验，所有外部输入在进入业务逻辑之前，必须做类型、长度、格式、范围的校验。第三层是数据访问层的参数化查询，这是最后也是最核心的防线。

参数校验这里，很多人只校验了是否为空，忽略了字符集的限制。比如用户名只允许字母数字和下划线，那就用正则^[a-zA-Z0-9_]{3,20}$严格限定。邮箱用RFC标准正则校验。手机号精确到数字长度。凡是能提前限定范围的，就不要留给后面的环节去判断。

还有一个容易被忽略的点是HTTP头部参数的注入。User-Agent、Referer、X-Forwarded-For这些头部字段，经常被记录到日志表或者用于统计分析。如果日志记录功能用的是拼接SQL，这些头部字段就是注入点。所有来自HTTP请求的数据，不管是GET参数、POST表单、Cookie还是Header，一律视为不可信输入。

SQL注入攻击很多时候依赖数据库报错信息来探测表结构。生产环境必须关闭详细的数据库错误回显，统一返回自定义的错误页面或JSON错误码。但关闭回显不等于不记录日志，恰恰相反，所有的SQL异常都应该详细记录到服务器日志里，包含完整的SQL语句、参数值、触发时间和用户IP。这些日志是发现注入攻击的重要线索。

日志记录时也要注意，敏感参数比如密码、令牌不能明文记录。可以写一个日志脱敏工具类，在记录SQL参数前对敏感字段做掩码处理。另外，日志文件本身的访问权限要严格控制，防止攻击者通过读取日志获取数据库结构信息。

有些老旧系统还在用addslashes或者mysql_real_escape_string这类转义函数来防注入。这类方案的问题在于，转义规则和数据库的字符集设置强相关。如果数据库用了GBK编码，攻击者可以通过宽字节注入吃掉转义符。正确的做法是彻底放弃转义思路，全面改用参数化查询。

如果因为历史原因确实存在必须拼接字符串的场景，比如动态构建LIKE模式或者处理JSON字段，那么至少要做到两点：一是对拼接内容做严格的类型转换和长度截断，二是用数据库驱动提供的官方转义API，而不是自己写正则。但必须明确，这只是临时过渡方案，最终目标还是重构为参数化查询。

JSON参数的场景现在越来越普遍，前端传一个JSON对象，后端解析后根据字段动态生成查询条件。这种情况下，每个字段的key和value都要做校验。key用白名单映射，value根据预期类型做强制转换。JSON解析库本身不会引发SQL注入，但解析后的数据如果直接拼SQL，风险是一样的。

再好的规范，如果没人遵守也是白费。代码审查时，凡是看到字符串拼接SQL的地方，直接标记为阻塞项。可以结合静态代码扫描工具，把SQL拼接的模式配置成高危规则。SonarQube、Fortify这些工具都能检测出常见的拼接模式，但自定义的封装方法可能需要手动配置规则。

单元测试里应该包含注入攻击的测试用例。用参数化测试传入各种注入payload，验证系统是否正确拦截或返回安全错误。这些测试用例本身就是一份活的攻击模式文档，新加入的开发者跑一遍测试就能直观感受到哪些写法是危险的。

说到底，动态参数场景下的SQL注入防御，技术方案已经很成熟了，参数化查询加白名单校验几乎能覆盖99%的场景。剩下的1%是人的问题：赶工期时随手拼接、老代码不敢动、对ORM框架盲目信任。安全机制要落地，除了技术手段，还需要在开发流程里卡住代码审查和自动化扫描这两道关。