如何防止SQL注入漏洞？

Question

如何在使用动态SQL时有效防止SQL注入攻击？许多开发者通过拼接用户输入构造SQL语句，导致恶意SQL代码被执行。例如，登录验证中直接拼接用户名和密码，攻击者可通过输入 `' OR '1'='1` 绕过认证。应如何正确使用参数化查询、预编译语句或ORM框架来防御此类攻击？同时，在无法使用参数化查询的场景（如动态排序、表名拼接），又该如何结合白名单校验、输入过滤与安全编码实践，确保SQL逻辑安全？

Answer 1

如何在使用动态SQL时有效防止SQL注入攻击

1. SQL注入的基本原理与常见场景

SQL注入是一种常见的Web安全漏洞，攻击者通过在用户输入中插入恶意SQL代码片段，改变原始SQL语句的逻辑。例如，在登录验证中，若开发者采用字符串拼接方式构造查询：

String sql = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'";

当攻击者输入用户名为 ' OR '1'='1 时，SQL语句变为：

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '...'

由于'1'='1'恒真，可能导致绕过认证机制。

2. 参数化查询：防御SQL注入的基石

参数化查询（Parameterized Queries）是防止SQL注入最有效的方法之一。它通过将SQL语句结构与数据分离，使数据库引擎能明确区分代码与数据。

以Java为例，使用PreparedStatement实现参数化：

String sql = "SELECT * FROM users WHERE username = ? AND password = ?";
PreparedStatement stmt = connection.prepareStatement(sql);
stmt.setString(1, username);
stmt.setString(2, password);
ResultSet rs = stmt.executeQuery();

此时即使输入包含SQL关键字，也会被当作普通字符串处理。

3. 预编译语句的工作机制分析

预编译语句在数据库层面预先解析SQL模板，后续仅传入参数值。其执行流程如下：

1. 客户端发送含占位符的SQL语句到数据库
2. 数据库解析并生成执行计划
3. 客户端发送参数值
4. 数据库绑定参数并执行
5. 返回结果集

此过程确保用户输入不会参与SQL语法解析，从根本上阻断注入路径。

4. ORM框架的安全优势与实践建议

主流ORM框架如Hibernate、MyBatis、Entity Framework等，默认支持参数化操作。例如在MyBatis中：

<select id="findUser" parameterType="map" resultType="User">
    SELECT * FROM users WHERE username = #{username} AND password = #{password}
</select>

其中#{}语法自动启用参数化，而${}则存在风险，应避免用于用户输入。

5. 动态SQL中的特殊场景与应对策略

某些场景无法使用参数化，如动态排序字段或表名拼接。此时需结合以下措施：

场景	风险点	解决方案
ORDER BY column	列名不能用参数占位	白名单校验 + 正则匹配
FROM table_name	表名需动态指定	枚举允许表名 + 输入过滤
LIMIT offset	偏移量可注入	类型转换 + 范围限制

6. 白名单校验与输入过滤实践

针对无法参数化的字段，必须实施严格校验。示例代码（Java）：

public boolean isValidSortColumn(String column) {
    Set<String> allowedColumns = Set.of("name", "created_time", "status");
    return allowedColumns.contains(column.toLowerCase());
}

public String sanitizeTableName(String input) {
    return input.matches("^[a-zA-Z_][a-zA-Z0-9_]*$") ? input : null;
}

同时建议对所有输入进行最小化原则处理：只允许必要字符。

7. 安全编码最佳实践汇总

构建纵深防御体系应包含以下层次：

• 默认使用参数化查询或ORM安全接口
• 禁用数据库特权账户运行应用
• 开启日志审计，监控异常SQL行为
• 定期进行安全扫描与渗透测试
• 实施最小权限原则（Principle of Least Privilege）
• 使用WAF作为辅助防护层
• 对开发者进行安全编码培训

8. 复杂动态SQL的安全架构设计

对于高度动态的查询构建，推荐使用QueryBuilder模式，并集成安全中间件。流程图如下：

graph TD
            A[接收用户请求] --> B{是否含动态结构?}
            B -- 是 --> C[白名单校验字段/表名]
            C --> D[正则过滤非法字符]
            D --> E[构造SQL模板]
            E --> F[参数化绑定变量]
            F --> G[执行查询]
            B -- 否 --> H[直接参数化查询]
            H --> G
            G --> I[返回结果]