如何使用预编译语句修复SQL注入-SQL-PHP中文网

预编译语句是修复sql注入的强制基线做法，因其在数据库层面将sql结构与参数物理隔离，使用户输入仅作为纯数据绑定而不参与语法解析；字符串拼接则导致数据库无法区分代码与数据，恶意输入如admin' --会直接篡改语句逻辑。

如何使用预编译语句修复sql注入

预编译语句（PreparedStatement）不是“可选加固项”，而是修复SQL注入的**强制基线做法**——只要涉及用户输入拼进SQL，就必须用它，没有例外。

为什么字符串拼接必然导致SQL注入

漏洞根源在于：数据库无法区分“代码”和“数据”。当你写 "SELECT * FROM users WHERE username = '" + username + "'"，恶意输入 admin' -- 会直接变成合法SQL的一部分，注释掉后续密码校验逻辑。数据库执行的是最终拼出的整条语句，而不是你“本意”想执行的那条。

常见错误现象包括：

登录页输 ' OR '1'='1 就能绕过验证
URL里加 id=1 UNION SELECT password FROM users 能查出其他用户密码
错误信息里暴露表名、字段名甚至数据库版本（如 MySQL 8.0.33）

Java中正确使用`PreparedStatement`的三步

核心是：**占位符 + 类型绑定 + 不拼接**。下面以JDBC为例：

错误写法（仍在拼接）：
String sql = "SELECT * FROM users WHERE username = '" + username + "'";
正确写法：

SearchGPT

SearchGPT是一款AI工具，OpenAI最新推出的AI搜索引擎。

下载

用 ? 占位，不插变量：String sql = "SELECT * FROM users WHERE username = ? AND password = ?";
调用 conn.prepareStatement(sql) 获取 PreparedStatement 对象
用类型明确的方法设参：pstmt.setString(1, username); pstmt.setString(2, password);（索引从1开始）

注意：setString 不是“转义字符串”，而是把值作为纯数据传给数据库驱动，由驱动按协议编码后发送——数据库收到的就是独立参数，不是SQL语法的一部分。

PHP里`mysqli_prepare`和`PDO::prepare`的关键区别

两者都支持预编译，但默认行为不同，容易踩坑：

mysqli_prepare：必须配合 mysqli_stmt_bind_param 使用，且参数类型需显式声明（如 "ss" 表示两个字符串）；漏掉绑定或类型错，会静默失败或报错 mysqli_stmt::execute(): (HY000/2031) No data supplied for parameters in prepared statement
PDO::prepare：更灵活，支持命名占位符（如 :username），且 execute() 可直接传数组；但要注意 PDO::ATTR_EMULATE_PREPARES 默认为 true（即PHP模拟预编译），这会退化为字符串拼接！必须关掉：$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

性能影响：真实预编译（emulate_prepares=false）会让SQL模板在数据库端缓存执行计划，重复查询更快；模拟模式则无此优势，且失去防注入保障。

哪些场景容易漏掉预编译

开发者常误以为“只读查询”或“数字ID”安全，其实只要输入未被隔离，就危险：

分页参数：ORDER BY ? 不合法（列名不能参数化），应白名单校验 $_GET['sort'] 是否在 ['id', 'name', 'created_at'] 中
IN 子句：WHERE id IN (?) 只能绑一个值；多个值需动态生成对应数量的 ?（如 WHERE id IN (?, ?, ?)），再逐个绑定
表名/列名：无法参数化，必须用白名单或正则严格匹配（如 ^[a-zA-Z_][a-zA-Z0-9_]*$）
动态条件拼接：先收集条件，再构建含固定占位符的SQL，避免运行时拼接字段名或操作符