PHP Web安全实战：SQL注入防护11年经验

　　PHP Web安全实战里，SQL注入防护这块儿——我啃了11年，从PHP5.2到PHP8.3，从手写SQL到用ORM，从黑名单过滤到参数化查询，最近刚处理完一个老项目的漏洞，那代码是2013年写的，用户输入直接拼进SQL里，攻击者通过`' OR 1=1--`就能绕过登录，数据库里20万条用户数据差点被拖走——这案子让我又想起2015年那回，某电商平台的订单查询接口，因为没对`limit`参数做过滤，被注入后直接导出了全站订单，损失超50万。

文章配图，仅供参考

　　但新技术也有坑——2020年我遇到个“假安全”案例：某项目用了PDO，但开发为了“方便”，把用户输入拼进`WHERE`条件里，比如`"WHERE id = {$userInput}"`，表面看是预处理，实际因为变量直接插值，PDO的绑定机制被绕过，攻击者输入`1; DROP TABLE users--`照样执行——这案子让我意识到：防护不是靠工具，是靠对工具的理解。后来我定了规矩：所有SQL必须用命名参数（`:id`这种），变量和SQL字符串必须严格分离，代码审查时重点查`{}`插值和字符串拼接。

　　近期处理的一个漏洞更离谱——某CMS系统，开发为了“兼容旧版”，在参数化查询里混用了`sprintf()`，比如`$sql = sprintf("SELECT FROM users WHERE name = '%s'", $name);`，然后外面再套一层PDO预处理——这操作等于先手动拼接SQL，再让PDO“二次处理”，攻击者输入`admin' --`，第一次拼接后SQL变成`SELECT FROM users WHERE name = 'admin' --'`，后面的`--`把后面的条件全注释了，直接绕过密码检查。这案子让我骂了三天街——防护不是叠buff，是得懂底层逻辑。

　　我主观判断：PHP里防SQL注入，参数化查询（PDO/mysqli）是基础，但真正安全得靠“防御性编程”——比如对所有用户输入做类型检查（`is_int($id)`）、长度限制（`strlen($name) < 50`），甚至白名单过滤（只允许字母数字）。去年我测过，即使参数化查询，如果对`order by`参数不做过滤，攻击者仍能注入`order by (CASE WHEN 1=1 THEN username ELSE password END)`，把密码字段曝出来——这招叫“盲注变种”，很多老防护方案根本防不住。

　　下一步我打算做个工具——自动扫描PHP代码里的SQL拼接点，标记出高危操作（比如`mysql_query()`、`sprintf()`+SQL），再结合运行时监控，实时拦截可疑查询。不过现在有个局限：有些老项目用框架的“便捷方法”（比如ThinkPHP的`Db::query()`直接传字符串），这些方法底层可能没强制参数化，得手动改代码——这活儿，估计还得再啃11年。

（编辑：52站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!