PHP站长11年实战：SQL注入防护精要

　　去年6月份，我接手一个老客户的PHP商城项目——2013年开发的系统，核心代码没动过，数据库用的还是MySQL 5.1。客户说最近总被刷订单，我查日志发现攻击者用`' OR 1=1--`这种老掉牙的SQL注入语句，居然还能绕过过滤，直接把后台订单表清空了。这事儿让我后背发凉——11年前我学PHP时，老师就强调过SQL注入，怎么现在还有人中招？

　　我翻出2012年写的第一套CMS系统，那时候防护全靠`mysql_real_escape_string()`，代码里全是`$sql = "SELECT FROM users WHERE username='".mysql_real_escape_string($_POST['user'])."'";`这种写法。后来发现这招根本不够——攻击者能通过`\x00`截断字符串，或者用`/!50000%20OR%201=1/`绕过MySQL版本检测。2015年我改用PDO预处理，结果测试时发现`bindParam()`的参数类型没设对，还是被注入成功——那次漏洞导致三个客户的数据库被拖库，赔了五万多块钱。

文章配图，仅供参考

　　但新技术也有坑——上个月有个客户非要用ThinkPHP 6.0的`query()`方法直接写SQL，说预处理影响性能。我拗不过他，结果上线第二天就被注入，攻击者通过`UNION SELECT`把管理员密码哈希全导出来了。后来查日志发现，他用了`$user->query("SELECT FROM users WHERE id={$id}")`——这哪是ThinkPHP？分明是2005年的写法！我直接给他装了SqlMap，扫出17个高危漏洞，他才乖乖改用模型查询。

　　说句主观的：现在还在手动拼接SQL的PHP站长，要么是懒，要么是真不懂安全——我见过太多人觉得“我的站小，没人攻击”，结果被黑后哭爹喊娘。去年6月那个商城项目，我花了三天时间把所有直接拼接SQL的地方改成预处理，又加了CloudFlare的WAF，现在每天拦截的注入攻击有200多次，但数据库再没出过问题。这年头，连WordPress都在用`wpdb::prepare()`，你还在用`mysql_query()`？

　　下一步我打算研究下AI在SQL注入防护里的应用——听说有团队用BERT模型分析SQL语句，能识别出0day注入手法。不过话说回来，再牛的技术也比不上开发者脑子里那根弦——我见过最离谱的案例，是有人把数据库密码硬编码在PHP文件里，还设成`123456`——这种“防护”，神仙也救不了。

（编辑：92站长网）

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