MySQL增删查改语句中，如何防止SQL注入？

Question

在使用MySQL进行增删查改操作时，若直接拼接用户输入到SQL语句中，攻击者可通过构造恶意输入（如 `' OR 1=1 --`）绕过认证或删除数据，导致SQL注入。常见问题：如何在PHP或Java等语言中，通过预编译语句和参数化查询有效防止此类攻击？

Answer 1

一、SQL注入攻击的本质与常见场景分析

SQL注入（SQL Injection）是一种典型的Web安全漏洞，攻击者通过在用户输入中插入恶意SQL代码片段（如 ' OR 1=1 --），篡改原始SQL语句的逻辑结构，从而绕过身份验证、非法获取数据甚至执行数据库管理操作。

例如，在登录验证中若使用如下拼接方式：

$sql = "SELECT * FROM users WHERE username = '" . $_POST['username'] . "' AND password = '" . $_POST['password'] . "'";

当用户输入用户名为 ' OR '1'='1，密码任意时，SQL语句变为：

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

由于 '1'='1' 恒为真，查询将返回所有用户记录，实现未授权访问。

二、防御核心：预编译语句与参数化查询原理

参数化查询（Parameterized Queries）和预编译语句（Prepared Statements）是防止SQL注入的黄金标准。其核心思想是将SQL语句的结构与数据分离：

• SQL模板在执行前被数据库预编译，形成执行计划；
• 用户输入作为参数传入，仅被视为数据，不会改变SQL语法结构；
• 数据库驱动自动对参数进行转义或类型化处理，杜绝恶意代码注入。

三、PHP中的实现方式：PDO与MySQLi对比

在PHP中，推荐使用PDO或MySQLi扩展来实现参数化查询。以下是两种方式的示例：

3.1 使用 PDO 进行参数化查询

$pdo = new PDO("mysql:host=localhost;dbname=test", $user, $pass);
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ? AND password = ?");
$stmt->execute([$_POST['username'], $_POST['password']]);
$user = $stmt->fetch();

3.2 使用命名参数提升可读性

$stmt = $pdo->prepare("SELECT * FROM users WHERE username = :username AND password = :password");
$stmt->bindParam(':username', $_POST['username']);
$stmt->bindParam(':password', $_POST['password']);
$stmt->execute();

3.3 MySQLi 面向对象风格示例

$mysqli = new mysqli("localhost", $user, $pass, "test");
$stmt = $mysqli->prepare("SELECT * FROM users WHERE username = ? AND password = ?");
$stmt->bind_param("ss", $_POST['username'], $_POST['password']);
$stmt->execute();
$result = $stmt->get_result();

四、Java 中的 PreparedStatement 实践

在Java中，PreparedStatement 是JDBC提供的用于执行预编译SQL语句的核心接口。

4.1 基本用法示例

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

4.2 防止DELETE注入攻击

假设删除操作基于用户ID：

String deleteSql = "DELETE FROM logs WHERE user_id = ?";
PreparedStatement delStmt = connection.prepareStatement(deleteSql);
delStmt.setInt(1, Integer.parseInt(userId));
delStmt.executeUpdate();

即使 userId 被构造为 1 OR 1=1，也不会导致全表删除。

五、技术对比与选型建议

特性	PDO (PHP)	MySQLi (PHP)	JDBC PreparedStatement (Java)
支持多数据库	✔️	❌（仅MySQL）	✔️（通过不同Driver）
预编译支持	✔️	✔️	✔️
命名参数	✔️	❌	❌（位置占位符）
异常处理	Exception机制	需手动检查	SQLException

六、高级防护策略与开发规范

除了使用预编译语句外，还需结合以下措施构建纵深防御体系：

1. 最小权限原则：数据库账户不应拥有DROP、ALTER等高危权限；
2. 输入验证：对用户输入进行白名单过滤（如正则匹配邮箱、手机号）；
3. 日志审计：记录所有SQL执行行为，便于溯源分析；
4. ORM框架集成：如Hibernate、MyBatis等默认支持参数化，减少手写SQL风险；
5. WAF辅助：部署Web应用防火墙识别异常请求模式；
6. 定期安全扫描：使用SQLMap等工具模拟攻击检测漏洞；
7. 错误信息脱敏：避免将数据库错误详情暴露给前端；
8. 使用存储过程（谨慎）：若使用，也应通过参数化调用；
9. 连接池安全管理：确保预编译语句在连接复用时不被污染；
10. 代码审查机制：建立SQL使用规范，禁止字符串拼接。

七、流程图：参数化查询执行流程

graph TD
            A[应用接收用户输入] --> B{是否使用预编译?}
            B -- 否 --> C[拼接SQL → 存在注入风险]
            B -- 是 --> D[定义SQL模板: SELECT * FROM users WHERE id = ?]
            D --> E[数据库预编译SQL模板]
            E --> F[绑定用户输入作为参数]
            F --> G[数据库执行参数化查询]
            G --> H[返回结果，无注入]

八、常见误区与反模式

尽管预编译是有效手段，但开发者常陷入以下误区：

• 误以为 addslashes() 可替代预编译：该函数无法应对宽字节注入等复杂场景；
• 动态表名/字段仍用拼接：预编译不支持表名占位，需通过白名单校验；
• ORM中自定义原生SQL未参数化：如HQL中使用+号拼接仍危险；
• Prepare重复执行未重用：每次新建Prepare影响性能；
• 认为HTTPS能防SQL注入：加密传输不等于数据安全。