PHP Web安全实战：SQL注入深度防护方案

　　PHP Web安全实战：SQL注入深度防护方案——这标题不是我随便起的，是去年十一月在给某省医保结算平台做渗透复测时，甲方安全团队盯着我改了七版报告才定下的名字。他们说“得让领导一眼看出价值”，我拗不过，就用上了。结果发现，这名字反而逼我挖出了PDO预处理里一个没人提过的边界bug：当prepare()传入含\\0字节的占位符名时，MySQL 5.7.32会静默截断导致绕过。那天下午三点十七分，我在测试机上连敲三遍show full processlist才确认不是网络抖动。

　　去年十一月，我们团队上线了医保平台V3.2，后端PHP版本锁定在7.4.33（别问为什么不用8.x——某老厂商中间件只认7.4）。上线第七天凌晨2:14，WAF日志突现127次/分钟的异常GET请求，User-Agent写着“Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.110 Safari/537.36”，但Referer全是空的——后来溯源发现是某外包公司用爬虫扫内网未授权接口时手误把SQLi payload塞进了header里的X-Forwarded-For字段，而我们当时漏掉了对所有HTTP头字段的参数化绑定校验。

　　PHP Web安全实战：SQL注入深度防护方案——我认为它优点在新技术。比如用PHP 8.1的Typed Property强制声明$stmt为PDOStatement类型，再配合AST分析插件phpstan-phpunit，在CI阶段直接报错“无法保证变量$id经过filter_var(INPUT_GET, FILTER_SANITIZE_NUMBER_INT)后仍能用于IN子句”。但这事去年十一月差点翻车：某同事在ORM层写了段反射调用get_class_vars()来动态生成WHERE条件，结果绕过了全部预处理逻辑——因为反射拿到的是原始字符串拼接值，PDO根本没机会介入。那周我删了三百行代码，重写了QueryBuilder的约束校验器。

　　某金融客户用ThinkPHP 6.0.12搭建的贷款审批后台，在2023年十月被通报存在SQL注入。漏洞成因特别刁钻：框架的whereRaw()方法允许传入闭包，而该闭包内部又调用了request()->param('id')，开发者以为闭包执行时框架会自动过滤——其实不会。我们在复现时发现，构造?id=1%20UNION%20SELECT%201,2,3,group_concat(table_name)%20FROM%20information_schema.tables%20WHERE%20table_schema=database()-- -，能直接拖出全库表名。补丁不是加白名单，而是强制所有whereRaw()调用前必须显式调用$builder->bind([':id' => $id])——哪怕这个$id明明是整数。

　　失败案例必须说：某政务云项目采用MySQL 8.0.28+PDO+SSL连接，理论上固若金汤。但开发组为兼容旧数据，把用户密码字段设为TEXT类型并启用fulltext索引。某次运维手动执行ALTER TABLE user ADD FULLTEXT(pwd)后，全文索引的MATCH AGAINST语法触发了MySQL Parser的一个隐式类型转换路径——当攻击者提交id=0 MATCH (pwd) AGAINST ('\\"or 1=1/' IN BOOLEAN MODE)时，PDO prepare机制彻底失效。这个洞直到今年二月审计时才被发现，中间被利用过两次，幸好日志只留了INSERT时间戳，没留原始payload。

文章配图，仅供参考

　　这方案不是银弹。

　　我亲手写了个AST插件，叫sqlguard-ast，它能扫描所有eval()、create_function()、preg_replace('/e/')、甚至call_user_func(array($obj,'__invoke'))这类高危调用链，但上周发现它对FFI扩展的cdata指针操作完全无感——你猜怎么着？某个合作方用FFI直接malloc内存块再用sprintf拼SQL，PDO根本管不着。现在我把这部分标记为“人力审计必查项”，下周一约对方架构师喝咖啡面聊。要不要一起？

（编辑：站长网）

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