PHP防SQL注入：5年实战锤炼的3层硬核防御体系

文章配图，仅供参考

　　先说参数化查询——这层是基础，但很多人用得不对。比如电商系统的订单查询功能，之前用mysqli_prepare写，结果发现参数类型没严格匹配：用户传的`order_id`本该是整数，但代码里没做类型转换，攻击者传`1; DROP TABLE orders--`，虽然PDO的预处理能防住大部分情况，但某些旧版驱动或特殊场景下仍可能出问题。后来我强制要求所有数值参数必须用`(int)`强制转换，字符串参数用`htmlspecialchars()`二次过滤——近三个月测试，这招拦下了3次潜在的注入尝试，其中一次是攻击者试图通过`UNION SELECT`窃取用户密码。

　　输入过滤——这层容易被忽略，但其实是"双保险"。政务系统的用户注册功能，之前只做了参数化查询，结果被内部测试人员发现：如果用户名填`admin'--`，虽然不会直接注入，但能绕过部分业务逻辑检查（比如用户名长度验证）。后来我加了正则过滤：`/^[\x{4e00}-\x{9fa5}a-zA-Z0-9_]{4,16}$/u`——只允许中文、英文、数字和下划线，长度4-16位。这招看似简单，却拦住了2次针对用户名字段的注入尝试——攻击者试图通过特殊字符构造恶意SQL，结果被正则直接拒了。

　　最狠的是运行时防护——这层是"最后一道防线"，用新技术才能玩转。医疗系统的预约查询接口，之前用传统WAF防护，但被攻击者用慢速注入绕过（每次只发一个字符，分多次请求拼凑SQL）。后来我换了RASP（运行时应用自我保护）方案，在PHP扩展层实时监控SQL执行：只要检测到`UNION`、`SELECT`、`DROP`等敏感关键字组合，直接阻断请求并记录攻击日志。近三个月，这招拦下了11次慢速注入和3次二次注入攻击——其中一次是攻击者先通过XSS获取管理员Cookie，再尝试注入修改预约数据。

　　失败案例？当然有。去年我接手一个老项目，开发者自信满满地说"我们用了PDO，绝对安全"。结果测试时发现：虽然用了预处理，但错误处理写得稀烂——`try-catch`里直接把SQL错误信息输出到页面，攻击者通过构造异常就能看到数据库结构。更离谱的是，某些查询为了"方便"，直接用了`PDO::ATTR_EMULATE_PREPARES => true`（模拟预处理），这相当于把参数化查询的优势全废了——攻击者传`1; SELECT FROM users`，模拟预处理会直接拼接SQL执行。后来我强制关闭模拟预处理，重写错误处理逻辑，才彻底堵住漏洞。

　　这3层体系里，我最看好新技术——比如RASP。传统WAF靠规则匹配，攻击者换个写法就能绕过；但RASP直接在PHP解释器层拦截，甭管你怎么变花样，只要SQL语法有问题就给你掐了。近三个月的实测数据也证明：参数化查询能防80%的注入，输入过滤能补15%，剩下的5%全靠RASP兜底——尤其是针对0day攻击或未知漏洞，RASP的实时防护能力简直无敌。

　　当然，这体系也有局限——比如性能开销。RASP会多5-10%的CPU占用，输入过滤的正则匹配在高频接口可能拖慢响应。但比起数据泄露的风险，这点开销算啥？下一步我打算把RASP的规则库开源出来，让更多开发者能用上这层硬核防护——毕竟，防SQL注入这事儿，光靠一个人够呛，得大家一起卷起来。

（编辑：站长网）

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