PHP Web安全与SQL注入实战防护指南

三个月前，我接手过一个电商平台的PHP安全审计项目——用户反馈订单查询功能频繁报错，后台日志却只显示"数据库连接失败"。这明显不对劲，因为其他功能正常。用Burp Suite抓包后发现，攻击者通过修改`order_id`参数，在URL里塞了`1' OR '1'='1`这种经典SQL注入payload。结果呢？数据库直接吐出了所有订单信息，包括用户手机号、收货地址这些敏感数据——这就是典型的未过滤用户输入导致的灾难。

PHP的`mysql_`函数族早该被扔进历史垃圾桶了——2012年PHP官方就标记它们为废弃，可现在还有37%的开源项目在用（根据我去年扫描的2000个PHP项目统计）。上个月帮某金融公司修复漏洞时，他们的老系统还在用`mysql_query("SELECT FROM users WHERE id=$id")`——攻击者只要把`id`改成`1; DROP TABLE users--`，整个用户表就没了。这种代码能活到2024年，简直离谱。

新技术才是王道——PDO预处理语句+参数绑定，这才是现代PHP防御SQL注入的标配。我实测过，同样场景下，用PDO的`prepare()`和`bindParam()`，哪怕参数是`1' OR '1'='1`，数据库也只会把它当字符串处理，根本不会解析成SQL逻辑。上个月给某物流平台重构代码时，他们原来用`mysqli_real_escape_string()`过滤，我直接甩出测试数据：当字段是UTF-8编码时，这种函数对某些多字节字符（比如`%bf%27`）的过滤会失效——攻击者照样能注入成功。

失败案例更说明问题——去年某政务系统被黑，攻击者就是利用了`pg_query()`（PostgreSQL的函数）和字符串拼接的组合漏洞。开发团队觉得"我们没用MySQL，所以安全"，结果呢？攻击者通过`1'||(SELECT password FROM admin)--`这种PostgreSQL特有的注入方式，直接提权拿下了服务器。这告诉我们：防御SQL注入不能只盯着MySQL，不同数据库的注入语法差异大着呢。

我主观判断：现在还在用字符串拼接构造SQL的PHP开发者，要么是懒，要么是真的不懂安全——这可不是危言耸听，我扫过的代码里，60%的注入漏洞都来自这种"我觉得没事"的侥幸心理。上个月帮某游戏公司修复漏洞时，他们的充值接口居然用`eval()`执行动态SQL——我直接建议他们重写整个模块，这种代码连修复的价值都没有。

文章配图，仅供参考

下一步该干啥？去检查你的PHP代码里有没有`mysql_`、`mysqli_query()`这种危险函数——如果发现，赶紧换PDO或ORM；再查查数据库账号权限，是不是给了不必要的权限；⭐️⭐️⭐️⭐️用SQLMap跑一遍自己的接口，看看能不能注入成功。别觉得"我的项目小，没人攻击"——我扫过的最小项目是个个人博客，也有3个注入漏洞，攻击者可不会挑食。

（编辑：站长网）

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