Laravel SQL注入防护_PDO预处理原理【教程】

最近发现不少小伙伴都对文章很感兴趣，所以今天继续给大家介绍文章相关的知识，本文《Laravel SQL注入防护_PDO预处理原理【教程】》主要内容涉及到等等知识点，希望能帮到你！当然如果阅读本文时存在不同想法，可以在评论中表达，但是请勿使用过激的措辞~

Laravel标准方法如where()、find()等天然防SQL注入，因其底层使用PDO预处理将SQL结构与数据分离；whereRaw()等裸SQL接口须手动绑定参数；动态字段名必须白名单校验；启用PDO::ATTR_EMULATE_PREPARES=false可增强安全性。

只要用 Laravel 的 where()、find()、update() 等标准方法，且不手动拼接 SQL 字符串，就基本不会被 SQL 注入——这不是靠“过滤”或“转义”，而是 PDO 预处理在底层把 SQL 结构和数据彻底分离了。

为什么 where() 天然安全？

它不是对输入做字符替换，而是调用 PDO::prepare() 生成带占位符的 SQL 模板（比如 SELECT * FROM users WHERE id = ?），再用 PDOStatement::execute() 单独传值。数据库服务器先编译语句结构，执行时只填数据，恶意字符串连解析机会都没有。

• 所有 Eloquent 和 Query Builder 的常规方法都走这条路，包括 insert()、delete()、orderBy()（但注意：字段名不能是用户输入）
• 即使传入 "1' OR '1'='1" 这种字符串，PDO 也会把它当纯文本塞进参数，不会改变 SQL 语义
• 底层不依赖 mysql_real_escape_string 类似逻辑，所以不惧编码绕过、宽字节等老套路

whereRaw() 和 selectRaw() 怎么用才安全？

这些方法跳过了框架的自动绑定，直接把字符串塞进 SQL，属于“裸 SQL 接口”，必须手动补上参数绑定，否则等于开门揖盗。

• 错误写法：whereRaw("email = '" . $request->input('email') . "'") —— 用户输入直接拼进 SQL
• 正确写法：whereRaw("email = ?", [$request->input('email')]) 或 whereRaw("email = :email", ['email' => $request->input('email')])
• 如果要动态字段或表名（如按用户选的 category 排序），绝不能用 orderBy($request->input('sort'))，必须走白名单校验：in_array($sort, ['name', 'created_at'], true) ? $sort : 'id'

为什么 ATTR_EMULATE_PREPARES = false 更可靠？

Laravel 默认用 PDO 的模拟预处理（ATTR_EMULATE_PREPARES = true），即 PHP 层自己拼 SQL + 转义；而设为 false 后，真正交由 MySQL 服务端预编译，杜绝客户端层面的解析歧义。

• 多语句注入（如 ; DROP TABLE users）在模拟模式下可能绕过，服务端原生预处理会直接报错
• 某些特殊编码组合（如 %A0 后接单引号）在模拟模式下可能被误判，原生模式由 MySQL 引擎统一处理编码上下文
• 修改方式：在 config/database.php 的 MySQL 配置里加 'options' => [PDO::ATTR_EMULATE_PREPARES => false]
• 注意：部分旧版 MySQL（

最危险的不是不懂怎么写 whereRaw()，而是以为 $fillable 或 $casts 能防注入——它们只管属性赋值和类型转换，跟 SQL 构造完全无关。真正关键的防线，始终是“结构与数据是否分离”，而这取决于你有没有让 PDO 去执行那一步 prepare()。

好了，本文到此结束，带大家了解了《Laravel SQL注入防护_PDO预处理原理【教程】》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！