mysql如何防止SQL注入攻击_使用预编译PreparedStatement-mysql教程-PHP中文网

PreparedStatement能防注入，因其将SQL语句模板与用户参数彻底分离：数据库先预编译含?占位符的语句，再将输入作为纯数据绑定，不参与语法解析，故恶意字符串如"admin' OR '1'='1"仅被视作值而非代码。

mysql如何防止sql注入攻击_使用预编译preparedstatement

为什么 PreparedStatement 能防注入

因为 PreparedStatement 把 SQL 语句和参数彻底分开处理：数据库先编译好带占位符（如 ?）的语句模板，再把用户输入作为纯数据绑定进去，不会参与语法解析。哪怕你传入 "admin' OR '1'='1"，它也只会被当做一个字符串值，不会拼进 SQL 逻辑里。

这和直接用字符串拼接（比如 "SELECT * FROM user WHERE name = '" + name + "'"）有本质区别——后者等于把用户输入直接喂给 SQL 解析器，风险完全不可控。

Java 中 PreparedStatement 的正确写法

关键不是“用了没”，而是“用对没”。常见错误包括手动拼接、漏设参数、类型不匹配：

必须用 ? 占位符，不能在 SQL 字符串里拼接变量
所有参数都得通过 setString()、setInt() 等方法绑定，不能靠 toString() 或字符串替换
占位符数量和 setXxx() 调用次数必须严格一致，否则抛 SQLException
批量操作要用 addBatch() + executeBatch()，别循环创建新 PreparedStatement

示例：

String sql = "SELECT * FROM users WHERE status = ? AND created_at > ?";
PreparedStatement ps = conn.prepareStatement(sql);
ps.setInt(1, 1);                    // status = 1
ps.setTimestamp(2, timestamp);       // 时间戳类型要匹配

哪些情况 PreparedStatement 也防不住

它只保护「参数值」，不保护「SQL 结构」。以下场景仍可能被注入：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

表名、字段名、排序字段（ORDER BY 后的内容）动态拼接：这些无法用 ? 占位，必须白名单校验或枚举
拼接 IN 子句（如 WHERE id IN (?, ?, ?)）：参数个数不确定时，得动态生成占位符，但生成逻辑本身不能拼用户输入
使用 setObject() 且传入恶意构造的自定义对象：极少见，但若 JDBC 驱动存在反序列化漏洞，可能绕过

例如 "SELECT * FROM " + tableName + " WHERE id = ?" —— 表名 tableName 若来自用户请求且未校验，就直接失效。

和 ORM 框架混用时的注意点

像 MyBatis、Hibernate 默认走预编译，但留了“方便入口”让人掉坑：

MyBatis 的 ${} 是字符串替换，#{} 才是预编译参数 —— 写成 SELECT * FROM ${table} 就等于裸奔
Hibernate 的 createNativeQuery() 如果拼接 SQL，同样不自动预编译；要用 setParameter() 显式绑定
JPA 的 @Query(nativeQuery = true) 注解下，占位符必须是 ? 或命名参数（:name），不能混用字符串拼接

本质上，只要最终落到 JDBC 层的是一个带 ? 的固定 SQL 模板，并由 PreparedStatement 执行，才真正受保护。

实际项目中最容易被忽略的，是那些看似“只是拼个表名”“只是动态加个字段”的地方——它们不在参数范围内，却常被当成普通变量一样信任。