PHP Web安全实战：SQL注入防护全解析

去年十二月份，我负责的一个PHP电商项目突然被黑客攻击——用户登录接口被注入恶意SQL，导致后台数据库里2000多条订单信息被篡改，客服电话直接被打爆。那会儿团队连夜排查，发现攻击者用的居然是最基础的`' OR 1=1--`语句，而我们的代码里还留着十年前的`mysql_query`函数，参数直接拼接进SQL语句里——这不就是给黑客递刀子吗？

后来我花了整整两周时间，把项目里的所有SQL交互都改成了预处理语句（Prepared Statements）。具体来说，就是用PDO的`prepare()`和`execute()`方法，把用户输入的参数用占位符（比如`:username`）代替，数据库引擎会先解析SQL模板，再单独处理参数——这样就算参数里带着`'; DROP TABLE users;--`这种鬼东西，也会被当成普通字符串处理，根本不会执行。实测下来，这种方法的防护效果比老式的`mysql_real_escape_string`强太多——后者只能防单引号，但遇到`\x00`这种特殊字符或者宽字节注入（比如GBK编码下`%bf%27`会被解析成`縗'`），照样会翻车。

不过光用预处理还不够——去年我在研究OWASP Top 10时发现，SQL注入的攻击手段早就进化了。比如“时间盲注”，攻击者会往SQL里塞`IF(SUBSTRING(password,1,1)='a',SLEEP(5),0)`这种条件语句，通过观察服务器响应时间来猜解密码；还有“布尔盲注”，靠返回页面的细微差异（比如错误提示是否存在）来逐步提取数据。这时候，单纯的预处理已经不够了，还得加上“最小权限原则”——数据库账户只给必要的权限，比如查询用`SELECT`，更新用`UPDATE`，绝对不能给`DROP`或`CREATE`这种高危权限。我测试过，就算攻击者绕过了预处理，只要账户没权限，也干不了大事——去年十二月那次攻击，如果数据库账户权限控制得当，最多只能改自己的订单，不会波及全库。

还有个容易被忽略的细节——Web应用防火墙（WAF）。我试过用ModSecurity，规则里加`942100`（SQL注入检测）和`942430`（限制特殊字符），能拦住大部分自动化工具的攻击。但有个坑——WAF的规则得定期更新，不然会被绕过。比如去年有个案例，攻击者用`1 EQL 1`（空格换成`%09`）代替`1=1`，老版本的WAF规则根本识别不了。我现在的方案是：预处理+最小权限+WAF三层防护，实测下来，去年十二月到今年三月，系统日志里再没出现过SQL注入的攻击记录——这可比单纯靠预处理稳多了。

不过说句实在的，新技术再牛，也得看人怎么用。我见过有人用PDO，但为了图方便，还是直接拼接参数进去——比如`$pdo->query("SELECT FROM users WHERE id = $id")`，这和用`mysql_query`有什么区别？还有的人用ORM框架（比如Eloquent），觉得框架自带防护，结果被“二次注入”坑了——比如用户输入的`username`被存进数据库时没过滤，后续查询时又被拼接进SQL，照样会被注入。所以我的判断是：PHP防SQL注入，新技术（预处理、最小权限、WAF）是基础，但更关键的是开发者的安全意识——得知道攻击者会怎么绕过你的防护，才能提前堵漏洞。

文章配图，仅供参考

（编辑：站长网）

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