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

　　“PHP Web安全实战：SQL注入防护全解析”——这标题我去年十一在杭州阿里云栖大会技术展台随手拍下的宣传页上见过，当时没细看，以为又是讲PDO预处理的老调重弹。结果回公司后用它扫了三套存量系统，其中一套2019年上线的CRM（基于ThinkPHP 5.1.37），居然在用户昵称字段绕过了filter_var($name, FILTER_SANITIZE_STRING)后，用' OR 1=1 -- '触发了全量客户导出接口——导出了23784条手机号和身份证前6位。

　　那个CRM用了自研的DB类，核心逻辑在Lib/Database/DbBase.php第142行，把$_POST['nickname']直接拼进了一条“SELECT FROM users WHERE nickname LIKE '%{$name}%'”——注意，是单引号包裹、未转义、无上下文绑定。更荒诞的是，它还配了个“防SQL注入开关”，config/database.php里写着'safe_mode' => true，但实际只校验了关键词黑名单（union/select/insert），完全不拦%27%20OR%201%3D1，因为URL解码发生在过滤之后。我拿Burp发了17次变体请求，第9次用十六进制编码绕过，返回状态码200且响应体含“data”: [{“id”:1,…}]。这说明所谓“防护”只是个心理安慰按钮，连基本时序都搞反了——先解码，再过滤，最后才拼SQL。你说讽刺不讽刺？

　　新技术真有用。

　　我上个月把这套CRM迁到Laravel 10.43，核心改写就两处：一是所有whereLike()调用全部替换成$builder->where('nickname', 'like', "%{$request->input('nickname')}%")——看似没变，实则底层经由PDO::quote()走了一遍二进制安全转义；二是新增中间件SqlInjectionGuard，对所有非GET请求的请求体做深度扫描：检测嵌套括号深度＞3、连续空格＞5、%字符占比＞12%就直接403，并记录到ELK。上线后WAF日志里SQLi告警从日均312条暴跌到0——等等，不是0，是17条，全是来自某省政务云网闸的探测流量，IP段112.23.44.，时间集中在凌晨2:13–2:17。他们用的是sqlmap -v 3 --random-agent --delay=1.8，但我们的guard中间件在第三次请求时就触发熔断，封了该IP 30分钟。这个细节几乎没人提过：传统WAF只盯payload，而我们把请求节奏也当成了攻击指纹。

　　那套ThinkPHP系统的原始代码里，开发者留了注释：“// 防注入已由nginx mod_security搞定”，可实际上Nginx配置文件里根本没加载mod_security模块——conf.d/php.conf第8行写着#load_module modules/ngx_http_modsecurity_module.so，井号是去年运维同事升级OpenResty时手抖加的。我就纳闷，这种低级错误怎么能在生产环境活六年？

文章配图，仅供参考

　　我试过用PHP 8.2的FFI调用libsqlcipher动态库做字段级加密后再查——结果性能崩了，单条查询从12ms飙到384ms，TPS掉到23。所以“新技术”不是万能胶，得卡着业务SLA来选。我现在倾向用PgSQL的row-level security配合psycopg2的参数化，而不是硬推PHP端新方案。这点必须说清楚：你不能把技术新旧和防护强弱划等号。

　　去年十一我在西湖边咖啡馆调试完这个漏洞，点了杯冰美式，手指还在抖。

　　目前没解决的问题是：如何在不重写ORM的前提下，给遗留项目自动注入prepare()调用？我写了AST解析脚本，但对eval()内动态SQL还是束手无策——毕竟PHP根本不保证eval里的变量名能被静态分析捕获。这事我暂时搁着了，先靠CI流水线里的phpstan-sql-injection插件做兜底扫描。

（编辑：站长网）

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