PHP防SQL注入：15年经验总结的3层硬核防御体系

去年7月份，我接手过一个电商平台的渗透测试项目——用户登录接口被检测出存在SQL注入漏洞，攻击者能通过构造`admin' --`这类payload直接绕过认证。这让我意识到，即便PHP生态已迭代到8.x版本，仍有大量项目依赖十年前的`mysql_real_escape_string()`函数，这种基于转义的防御在Unicode编码、宽字符注入等新型攻击面前形同虚设。我的15年经验告诉我：真正的防御必须覆盖输入、处理、输出全链路，形成三层硬核体系。

第一层是预处理语句的强制绑定——别跟我说什么"PDO比mysqli慢"，我实测过千万级数据量的电商系统，开启持久化连接后，PDO的预处理性能损耗不到3%，但能彻底阻断字符串拼接导致的注入。去年处理的那个漏洞，开发者居然还在用`$sql = "SELECT FROM users WHERE username='".$_POST['user']."'";`这种代码，攻击者只需在用户名输入框填入`admin' OR 1=1 --`，数据库就会返回所有用户数据。换成PDO后，参数必须通过`bindParam()`或`execute([])`传递，SQL语句和参数完全分离，攻击者连注入的缝隙都找不到。

第二层是数据类型的严格校验——很多人以为只要用了预处理就万事大吉，但去年我见过更离谱的案例：某金融系统的转账接口，虽然用了PDO，但开发者没对`$amount`参数做类型检查，攻击者通过`?amount=1 OR 1=1`构造注入，直接绕过了金额校验。我的方案是：在接收参数时，用`filter_var($_POST['amount'], FILTER_VALIDATE_INT)`强制转换为整数，如果是浮点数就用`FILTER_VALIDATE_FLOAT`，字符串类型则限制长度（比如用户名不超过20字符）。去年7月修复的那个电商平台漏洞，就是在这一层加了`ctype_digit()`检查ID参数，直接拦截了`?id=1 UNION SELECT`这类攻击。

第三层是存储过程的深度隔离——这招是我从处理银行系统时学来的。2018年，某城商行的核心系统被曝出SQL注入，攻击者通过调用未授权的存储过程篡改了账户余额。我的做法是：把所有数据库操作封装成存储过程，PHP端只传递参数，不直接执行SQL。比如用户登录，不是写`SELECT FROM users WHERE username=? AND password=?`，而是调用`sp_user_login(?,?)`存储过程，权限控制在数据库层面，PHP应用账号只有执行存储过程的权限，没有直接查询表的权限。去年测试时，我尝试用`?username=admin'; EXEC sp_add_admin --`注入，数据库直接报错权限不足——因为存储过程内部已经做了参数校验和日志记录。

有人会说："这三层太复杂了，小项目用不上"——但去年7月那个电商平台，就是因为觉得"用户量少不用搞这么复杂"，结果被黑产利用漏洞刷走了价值50万的优惠券。我的主观判断是：这三层防御不是"可选配置"，而是"必选项"，尤其是涉及资金、用户数据的系统。新技术带来的不是负担，而是更高效的防御——比如PHP 8.1的`PDO::ATTR_EMULATE_PREPARES`选项，能强制使用原生预处理，避免模拟预处理的兼容性问题；再比如Laravel的`Eloquent ORM`，底层已经封装了参数绑定，开发者不用手动写PDO代码，反而更安全。

文章配图，仅供参考

（编辑：91站长网）

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