如何防止SQL恶意注入导致数据被删_使用预编译参数化查询-SQL-PHP中文网

SQL注入风险源于字符串拼接使用户输入被当作SQL代码执行，预编译通过参数与语句分离从语法层面阻断，所有用户输入必须进参数，动态字段需白名单校验，ORM原生SQL或日志拼接同样危险。

如何防止sql恶意注入导致数据被删_使用预编译参数化查询

为什么 `string.Format` 或拼接 SQL 字符串会直接导致删库

因为数据库把拼进去的字符串当真实 SQL 执行，' OR 1=1; DROP TABLE users; -- 这种输入，后端一拼就变成完整可执行语句。预编译不是“过滤”，而是从语法层面切断变量和 SQL 结构的混合——参数永远只是值，不会被解析成关键字或语句。

常见错误现象：System.Data.SqlClient.SqlException: Incorrect syntax near 'xxx' 或更危险的静默执行成功；用 WHERE name = '{input}' 查用户时，输 admin'-- 就绕过密码。

所有用户可控输入都必须进参数，包括分页 offset、limit、ORDER BY 字段名（后者需白名单校验，不能参数化）
.NET 中 SqlCommand 的 Parameters.Add() 比 AddWithValue() 更安全——后者可能推断错类型，引发隐式转换或索引失效
Java 的 PreparedStatement 必须用 ? 占位，不能写成 "WHERE id = ? AND status = '" + status + "'"

MySQL/PostgreSQL 中 `PreparedStatement` 的实际写法差异

MySQL 官方驱动默认关闭服务端预编译，useServerPrepStmts=true 才真正走二进制协议；PostgreSQL 的 Npgsql 默认启用，但参数名必须用 @name（SQL Server 风格）或 :name（原生风格），混用会报 42703: column "xxx" does not exist。

使用场景：批量插入、动态条件查询、存储过程调用。

MySQL 连接字符串加 ;useServerPrepStmts=true;cachePrepStmts=true，否则 Prepare() 只是客户端模拟
PostgreSQL 中 WHERE name ILIKE :pattern，参数名冒号不能漏；ILIKE 是 PostgreSQL 特有，MySQL 要用 LOWER(name) LIKE LOWER(:pattern)
Oracle 的 :name 和 SQL Server 的 @name 不互通，换数据库时别直接复制粘贴参数占位符

`ExecuteScalar` 和 `ExecuteReader` 也要参数化吗

要。只要 SQL 字符串里包含任何用户输入，不管执行什么方法，都得参数化。很多人以为只有 ExecuteNonQuery（增删改）危险，其实 SELECT 泄露数据、ExecuteScalar 返回伪造 ID、ExecuteReader 被注入 UNION SELECT 都是高危操作。

典型错误：用 ExecuteScalar 查登录态，写成 "SELECT id FROM users WHERE email = '" + email + "' AND pwd = '" + pwd + "'" —— 输 admin@example.com' AND 1=1 UNION SELECT 'hacked'-- 就能绕过验证。

ExecuteScalar 示例：cmd.CommandText = "SELECT COUNT(*) FROM logs WHERE level = @level AND ts > @since"; cmd.Parameters.Add("@level", SqlDbType.VarChar).Value = inputLevel;
ExecuteReader 里别在循环中反复 cmd.Parameters.Clear() 再 Add——用 cmd.Parameters["@id"].Value = nextId 复用更高效
ORM 如 Dapper、EF Core 默认参数化，但手写 connection.Query("SELECT * FROM t WHERE id = " + id) 就破防了

哪些地方「看起来像参数化」其实没用

用 ORM 的 Where(x => x.Name == input) 是安全的，但一旦切到原生 SQL，哪怕只拼一个表名、字段名或 IN 列表，就退回高危区。这类“半参数化”最骗人。

性能影响：预编译本身几乎无开销，但滥用字符串拼接 + 参数混合（比如 "SELECT * FROM " + table + " WHERE id = @id"）会导致每次 SQL 文本不同，数据库无法复用执行计划，缓存命中率暴跌。

IN 列表必须展开为独立参数：WHERE id IN (@p1, @p2, @p3)，不能传一个逗号字符串再 FIND_IN_SET 拼接
表名、列名、排序方向（ASC/DESC）无法参数化，必须走白名单校验：if (!new[] { "created_at", "score" }.Contains(sortField)) throw ...
MyBatis 的 ${xxx} 是字符串替换，#{xxx} 才是参数化——看错符号等于没防

最容易被忽略的是日志记录和调试输出：把原始 SQL 拼接后打到日志里，等于把攻击 payload 直接写进磁盘。查问题时宁可用参数化后的 cmd.Parameters 逐个打印值，也别拼完整语句。