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

发布时间：2026-10-12 08:27:16 所属栏目：PHP教程来源：DaWei

导读：去年八月份，我接手一个电商平台的PHP项目，上线第三天就被黑客用SQL注入攻击了——攻击者通过用户登录页面的`username`参数，直接注入`admin' --`，把密码验证逻辑绕过去了。那会儿数据库里2000多条用户信息差点被拖走，修复

去年八月份，我接手一个电商平台的PHP项目，上线第三天就被黑客用SQL注入攻击了——攻击者通过用户登录页面的`username`参数，直接注入`admin' --`，把密码验证逻辑绕过去了。那会儿数据库里2000多条用户信息差点被拖走，修复时发现漏洞点竟是开发团队用了三年的“万能查询函数”——直接拼接SQL语句，连最基本的`mysqli_real_escape_string()`都没用。

这事儿让我彻底意识到：PHP的SQL注入防护，光靠“转义字符”这种老方法早不够用了。现在攻击者用的工具能自动扫描参数，甚至能绕过WAF（Web应用防火墙）的规则——比如用`1' OR 1=1--`这种经典注入语句，现在会被改写成`1' OR (SELECT 1 FROM (SELECT COUNT(),CONCAT(0x716b6a6b71,(SELECT (ELT(9031,0x717a6a7171))),0x71786a6b71,FLOOR(RAND(0)2))x FROM INFORMATION_SCHEMA.PLUGINS GROUP BY x)a)--`，直接绕过简单的过滤逻辑。

新技术里，我最推荐预处理语句（Prepared Statements）——不是那种“伪预处理”的拼接SQL，而是用PDO或mysqli的`prepare()`+`bindParam()`。去年十月，我重构了那个电商平台的用户查询模块，把所有动态参数都用`?`占位符替换，再绑定变量。测试时故意传`' OR '1'='1`这种恶意参数，数据库直接报错“参数未绑定”，根本不执行SQL拼接——这招能防90%以上的基础注入攻击。

还有个细节容易被忽略：PHP的`filter_input()`函数。很多人以为它只能过滤`INPUT_GET`或`INPUT_POST`，其实它还能配合`FILTER_SANITIZE_STRING`和`FILTER_FLAG_STRIP_LOW`，直接过滤掉控制字符和特殊符号。去年十二月，我在一个论坛系统的搜索功能里加了这层过滤，结果拦截了300多次带``标签的注入尝试——虽然这些攻击者可能只是想XSS，但说明过滤输入比单纯转义更彻底。

失败案例？太多了。上个月有个同行用Laravel框架，觉得框架自带的安全机制够强，结果被攻击者通过`whereRaw()`方法注入成功——Laravel的查询构建器虽然能防大部分注入，但`raw()`方法会直接执行原始SQL，他没对参数做二次校验。这事儿说明：新技术再强，也得看开发者怎么用——就像给了你一把防弹衣，你非把弹孔对着自己，能怪谁？

主观判断：PHP的SQL注入防护，预处理语句+输入过滤+最小权限原则，这三板斧足够应对95%的攻击场景。那些说“新技术没用”的，要么是没试过，要么是偷懒不想改旧代码——我见过太多项目，数据库账号是root，表权限是ALL，这种情况下，就算用再高级的防护技术，也是白搭。

文章配图，仅供参考

下一步行动？如果你现在还在用`mysql_query()`拼接SQL，赶紧停手——这玩意儿PHP 7.0就移除了，用PDO或mysqli的预处理。要是项目里有“万能查询函数”，立刻重构，别等被攻击了才后悔。当然，我也承认局限：有些老系统用着过时的PHP版本（比如5.x），没法用PDO，这时候只能用`mysqli_real_escape_string()`+严格的白名单过滤——虽然麻烦，但总比裸奔强。

（编辑：站长网）

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