PHP怎么防范SQL注入

wen PHP项目 2026-08-11 2

本文目录导读：

PHP怎么防范SQL注入

目录导读
理解威胁：SQL注入是如何发生的？
第一道防线：PDO预处理语句（标准答案）
第二道防线：MySQLi转义与类型绑定（传统方案）
进阶加固：输入过滤、存储过程与最小权限原则
实战问答：围绕“magic_quotes”“双重编码”“ORM”的常见误区
检测与监控：如何发现已有注入点？
总结清单：5个必守底线

PHP防SQL注入终极指南：从基础防御到高级规避策略（2025版）

目录导读

理解威胁：SQL注入是如何发生的？
第一道防线：PDO预处理语句（标准答案）
第二道防线：MySQLi转义与类型绑定（传统方案）
进阶加固：输入过滤、存储过程与最小权限原则
实战问答：围绕“magic_quotes”“双重编码”“ORM”的常见误区
检测与监控：如何发现已有注入点？
总结清单：5个必守底线

理解威胁：SQL注入是如何发生的？

SQL注入的本质是用户输入被拼接到SQL语法结构中，导致解释器分不清“代码”与“数据”。

$sql = "SELECT * FROM users WHERE name = '$user_input'";

当输入是' OR '1'='1时，条件恒成立，攻击者绕过了认证。危险点：任何直接拼接（$conn->query、mysqli_query）都可能成为突破口。

第一道防线：PDO预处理语句（标准答案）

PHP官方推荐的做法是使用PDO（PHP Data Objects）的预处理语句，核心逻辑是参数化查询：SQL结构与数据分开发送，数据库先编译结构，再绑定参数值,数据永远不会被视作代码。

$pdo = new PDO('mysql:host=localhost;dbname=test', $user, $pass);
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false); // 关键：禁用模拟预处理
$stmt = $pdo->prepare('INSERT INTO users (name, email) VALUES (:name, :email)');
$stmt->execute([':name' => $_POST['name'], ':email' => $_POST['email']]);

问答环节：
问：为什么我用了PDO还是被注入？
答：多数是因为 PDO::ATTR_EMULATE_PREPARES 设为 true（默认值），这会让PDO在客户端本地模拟预处理，实际上仍是拼接后发送，必须显式设为 false 才能真正使用数据库原生预处理。

第二道防线：MySQLi转义与类型绑定（传统方案）

若你使用mysqli，必须执行两步：

类型绑定：$stmt->bind_param('is', $id, $name);（i整数，s字符串）
字符集安全：$conn->set_charset('utf8mb4') 防止宽字节绕过。

关键警告：不要依赖 mysqli_real_escape_string() 作为唯一手段，它只能转义已知特殊字符，但存在编码绕过（如GBK中 %bf%27）,且无法保护数字类型列。

问答环节：
问：addslashes() 和 mysqli_real_escape_string() 足够吗？
答：绝对不够，它们只处理字符串引号，但若查询使用了 LIKE、IN、ORDER BY 等非字符串场景，攻击者可用无引号注入，且若数据库连接字符集为GBK，addslashes 可被宽字节绕过。

进阶加固：输入过滤、存储过程与最小权限原则

输入过滤（白名单）：对于枚举值（如 status），用 in_array 限定范围；对于数字，用 filter_var($input, FILTER_VALIDATE_INT)。过滤是纵深防御,不能替代预处理。
存储过程：将复杂SQL封装在数据库端，PHP仅调用 CALL proc(?,?)，这能隐藏表结构，但存储过程内部若仍拼接，同样危险。
最小数据库权限：应用账号只授予 SELECT, INSERT, UPDATE，不授予 DROP, FILE，即使被注入,也难以提权读取敏感文件。

问答环节：
问：使用ORM框架（如Eloquent）就绝对安全了吗？
答：ORM底层走PDO预处理，安全，但使用原生查询方法（如 DB::raw()）时，若拼接用户输入，依然会注入，ORM不是保险箱,关键在开发习惯。

实战问答：围绕“magic_quotes”“双重编码”“ORM”的常见误区

误区1：magic_quotes_gpc 已废弃（PHP5.4移除）,别再在代码中依赖它。
误区2：urldecode() 二次解析导致双重编码绕过。处理顺序：先取原始输入（不要对 $_GET/$_POST 再解码）,除非你有明确编码转换需求。
误区3：json_decode 或 unserialize 后的字符串不检查就拼接。这类数据同样需要预处理。

问：如何用正则过滤危险字符作为附加保护？
答：建议不写复杂正则，因攻击变种多，若必须，可仅保留白名单字符，preg_replace('/[^a-zA-Z0-9_\-]/', '', $input)，但会破坏用户体验,且不能覆盖二进制攻击。

检测与监控：如何发现已有注入点？

静态扫描：搜索代码中的 $_GET、$_POST、$_REQUEST 直接出现在 query()、exec() 或字符串拼接处。
动态测试：使用 sqlmap 等工具对PHP站点进行自动化注入风险探测,但注意需授权。
日志监控：检查数据库错误日志，若出现 syntax error near 或 You have an error in your SQL syntax,极有可能是注入尝试。

总结清单：5个必守底线

一律使用PDO预处理（关闭模拟预处理）或 mysqli_stmt_bind_param。
绝不拼接用户输入到SQL字符串（包括 ORDER BY、LIKE 模式）。
数据库账号最小权限,对应应用只用必要的CRUD。
所有外部数据（GET/POST/Cookie/Header）都视为不可信,不做任何假设。
不依赖转义函数作为第一防线,只作为纵深补充。

最后建议：安全是一场持久战，在写代码时，默认使用 $pdo->prepare() 范式，并配合代码审查与自动化测试,将注入风险在团队层面归零。