PHP防SQL注入技巧与安全查询方法

本文深入剖析了PHP中防御SQL注入的核心策略，明确指出预处理语句（Prepared Statements）是当前最可靠、最标准的解决方案——通过PDO或MySQLi实现SQL结构与数据的彻底分离，从根本上杜绝注入风险；文章犀利批判了mysql_real_escape_string等过时转义手段的严重缺陷，包括宽字节漏洞、类型不安全、盲注无效及PHP 7+废弃等问题，并以清晰代码示例对比PDO的简洁灵活与MySQLi的严谨繁琐，最终强调：真正的安全不在于单点技术选型，而在于全项目统一贯彻预处理原则，堵住任何一处字符串拼接的后门。

PHP 查询语句防注入，最可靠的方式就是**不用拼接 SQL 字符串，改用预处理（Prepared Statements）**。其他所谓“过滤”“转义”“正则替换”都是补丁式做法，容易漏、难维护、不通用。

为什么 mysql_real_escape_string 不够用

这个函数只对单引号、反斜杠等做转义，但仅适用于 mysql_query 且必须配合单引号包裹变量——一旦漏写引号，或用于数字型字段未加引号，立刻失效。更严重的是：mysql_* 函数在 PHP 7.0+ 已被彻底移除，继续用等于主动放弃安全更新和语言支持。

• 它无法防御基于布尔/时间的盲注
• 对多字节编码（如 GBK）存在宽字节注入漏洞
• 不能保证类型安全：字符串转义后仍可能被当作数字参与运算

PDO 预处理 + 参数绑定是当前标准解法

PDO 的 prepare() 和 execute() 将 SQL 结构与数据完全分离，数据库驱动层负责把参数按类型安全地传入，根本不会解析成 SQL 代码。哪怕用户输入 ' OR 1=1 -- ，也只会当做一个普通字符串值处理。

$pdo = new PDO('mysql:host=localhost;dbname=test', $user, $pass);
$stmt = $pdo->prepare('SELECT * FROM users WHERE id = ? AND status = ?');
$stmt->execute([$_GET['id'], 'active']); // 自动识别类型，无需手动转义
$user = $stmt->fetch();

• 问号占位符（?）适合简单场景；命名参数（:name）更适合复杂查询，可重复使用
• execute() 接收数组时，所有值默认按字符串处理；如需指定类型，用 bindValue() 显式声明 PDO::PARAM_INT 或 PDO::PARAM_BOOL
• 确保 PDO 设置了 PDO::ATTR_EMULATE_PREPARES => false（默认 MySQL 驱动已启用真预处理）

MySQLi 同样支持预处理，但写法稍繁琐

MySQLi 面向对象风格也能做到同等防护，只是步骤更多：先 prepare()，再用 bind_param() 绑定变量类型和值，最后 execute()。类型字符串中 i（int）、s（string）、d（double）、b（blob）必须严格匹配，否则绑定失败或结果异常。

$mysqli = new mysqli('localhost', $user, $pass, 'test');
$stmt = $mysqli->prepare('SELECT name FROM products WHERE category = ? AND price > ?');
$stmt->bind_param('si', $_GET['cat'], $_GET['min_price']); // 注意类型顺序和变量引用
$stmt->execute();
$result = $stmt->get_result();

• bind_param() 的第一个参数是类型字符串，后续必须传变量（不是值），所以要提前定义好变量
• 如果参数来自数组或动态生成，PDO 的数组传参方式更灵活
• MySQLi 过程式写法（mysqli_prepare() 等）已基本被弃用，不建议新项目采用

真正麻烦的从来不是“怎么写预处理”，而是**如何让整个项目里所有 SQL 调用都走这一条路**——ORM、查询构建器、旧代码迁移、第三方库集成，都会带来例外情况。一旦某个角落用了 mysqli_query("SELECT * FROM t WHERE id = " . $_GET['id'])，整套防护就形同虚设。

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