PHP防SQL注入技巧全解析

本文深入剖析了PHP中真正可靠、可落地的SQL注入防护方案，明确指出仅依赖PDO预处理语句（配合`PDO::ATTR_EMULATE_PREPARES => false`显式关闭模拟预处理）或MySQLi的`bind_param()`才是当前唯一有效的防御手段，而`addslashes()`等传统方法早已失效且极易被宽字节注入绕过；文章还关键揭示了开发者常踩的致命陷阱——如未校验表名/字段名等标识符（必须白名单硬控制）、动态查询中通配符拼接不当、忽略输入类型与业务范围校验（如limit越界、邮箱格式缺失验证），以及绑定参数时类型错配、引用缺失等细节失误如何让整套防护形同虚设，堪称一份直击生产环境痛点的实战防注入指南。

用 PDO::prepare() + bindValue() 或 execute() 绑定参数是当前唯一可靠、可落地的防 SQL 注入方式。其他方法（比如 addslashes()、mysql_real_escape_string()）要么已废弃，要么在宽字节、字符集错配等场景下会被绕过。

为什么 PDO::ATTR_EMULATE_PREPARES => false 必须显式关闭

PHP 默认开启模拟预处理（emulate prepares），即 PDO 把占位符替换成字符串再发给 MySQL —— 这本质上还是拼接，只是换了个写法。一旦遇到 GBK 等多字节编码或连接层未设 charset，'%df' OR 1=1 -- 这类宽字节注入就能穿透。

• 必须在构造 PDO 实例时传入：[PDO::ATTR_EMULATE_PREPARES => false, PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION]
• 不设 PDO::ATTR_ERRMODE，绑定失败或执行出错时会静默失败，你根本不知道防护已失效
• 用 var_dump($pdo->getAttribute(PDO::ATTR_EMULATE_PREPARES)) 可验证是否生效

bind_param() 在 MySQLi 中的类型和引用陷阱

MySQLi 的 bind_param() 看似简单，但两个细节错一个就白忙：类型字母必须对、变量必须传引用。

• 类型标识只能是 i（int）、d（double）、s（string）、b（blob）；写成 'si' 却传了两个字符串，第二个值会被截断或丢弃
• 参数必须是变量引用：$stmt->bind_param('ss', $ip, $action)，不能写成 bind_param('ss', $_SERVER['REMOTE_ADDR'], $_POST['action'])，否则报 Number of variables doesn't match number of parameters
• 别混用：bind_param() 已经做了安全绑定，再对同一变量调 mysqli_real_escape_string() 不仅多余，还可能因二次转义导致数据异常

表名、字段名、ORDER BY 为什么不能参数化

SQL 语法规定：占位符 ? 或 :name 只能用于数据值，不能用于标识符（identifier）。数据库在 prepare 阶段就要解析语句结构，而表名/排序字段属于结构的一部分。

• 错误写法：SELECT * FROM ? WHERE status = ? → 直接报错
• 正确做法：白名单硬校验，例如 in_array($_GET['sort'], ['id', 'name', 'created_at'], true)，不匹配就拒掉或 fallback 到默认字段
• 动态 LIKE 模糊查询需注意：通配符（%、_）要由 PHP 拼进变量值里，再绑定，而不是写死在 SQL 中，否则会失去索引加速效果

最常被忽略的是：即使用了预处理，也得校验输入类型和范围。比如 $_GET['limit'] 是数字，但攻击者可能传 999999999999 导致全表扫描；$_POST['email'] 即使绑定了，也得先用 filter_var($email, FILTER_VALIDATE_EMAIL) 过一遍——预处理防的是语法篡改，不是业务逻辑崩坏。

以上就是《PHP防SQL注入技巧全解析》的详细内容，更多关于的资料请关注golang学习网公众号！