MySQL数据库如何应对SQL盲注带来的安全威胁？-mysql教程-PHP中文网

唯一能防住布尔盲注的是强制参数化查询（mysqli_prepare或pdo::prepare），因addslashes和mysqli_real_escape_string在宽字节编码下可被绕过，且对数字型参数完全无效；动态标识符须白名单校验，所有用户输入路径都必须覆盖。

mysql数据库如何应对sql盲注带来的安全威胁？

直接上结论：光靠过滤单引号、隐藏错误、统一返回文案，防不住布尔盲注；唯一能切断攻击链的，是让用户输入彻底失去“变成SQL代码”的能力——也就是强制走 mysqli_prepare 或 PDO::prepare。

为什么 addslashes 和 mysqli_real_escape_string 会失效

这两个函数只在特定字符集（如 latin1）下有效。一旦数据库连接使用 gbk 或 big5，攻击者可用 %A1%AA 这类宽字节绕过转义；更关键的是，它们对数字型参数完全无效——比如 id=1 后面直接接 AND 1=1，根本没单引号可逃。

常见错误现象：

页面对 id=1 AND 1=1 和 id=1 AND 1=2 返回不同内容（如“存在”/“不存在”）
日志里查不到报错，但 sqlmap 跑出数据库名和表结构

实操建议：

检查当前连接字符集：mysqli_set_charset($conn, 'utf8mb4')，并确保 MySQL 服务端也设为 utf8mb4
禁用 addslashes 做 SQL 防御，它不是为此设计的
数字型参数必须显式类型转换：$id = (int)$_GET['id'];，但仅限于确定为整数的场景

参数化查询必须覆盖所有分支路径

很多人只在主查询用了 mysqli_prepare，却在权限校验、日志记录、分页计算等次要逻辑里继续字符串拼接，等于留了一扇没锁的后门。

使用场景：

MySQL

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

下载

WHERE 条件、ORDER BY 字段、LIMIT 偏移量（注意：LIMIT 参数不能直接参数化，需先转成 int）
INSERT 的 VALUES、UPDATE 的 SET 子句、DELETE 的条件

示例对比：

// ❌ 错误：拼接 LIMIT
$sql = "SELECT * FROM users LIMIT " . $_GET['offset'] . ", 10";
<p>// ✅ 正确：先校验再拼接，或改用预处理 + 绑定
$offset = (int)$_GET['offset'];
$sql = "SELECT * FROM users LIMIT ?, 10";
$stmt = mysqli_prepare($conn, $sql);
mysqli_stmt_bind_param($stmt, "i", $offset);
</p>

容易踩的坑：