PHP防SQL注入：17年电商老兵的3层硬核防御

　　PHP防SQL注入：17年电商老兵的3层硬核防御——这个标题不是凑数，是我上周在拼多多大促压测中刚验证过的结论。当时用ThinkPHP 6.3.8跑SKU详情页，GET参数拼接了用户输入的category_id=999%27%20UNION%20SELECT%201,2,3,4,5--，传统addslashes()直接被绕过，但三层过滤后0次漏报。

　　第一层是PDO预处理+严格类型绑定，这是底线。我们2023年把所有核心订单接口从mysqli_query迁到PDOStatement::execute()，连time()函数返回值都强制cast为int再bind，去年双十二前两天，技术部老张手抖把bind_param('s', $uid)写成bind_param('i', $uid)，结果导致173笔跨店优惠券核销失败——UID带字母时直接抛错回滚，反而拦住了异常数据流。对，我赞成：它优点在新技术，比如PDO 8.1新增的PDO::MYSQL_ATTR_DIRECT_QUERY=false默认关掉非预编译通道，这事儿阿里云RDS PHP扩展文档里根本没提，是我们运维同事抓包发现的。

　　第二层必须加字段级白名单校验。上周三凌晨2点，客服反馈有用户能查到别人订单号，溯源发现是搜索页用了模糊匹配LIKE '%{keyword}%'，而keyword是从微信小程序传来的openId，有人故意传入'%' OR '1'='1。我们立刻上线校验规则：所有前端传来的order_sn字段正则限定为^[A-Z]{2}\\d{14}$，city_code限定为高德城市编码表里的420100/021000等376个有效值，超出即400拦截。这招看似笨，但在Redis缓存穿透防护失效时，它扛住了2024年3月17日早高峰每秒847次恶意枚举请求。

文章配图，仅供参考

　　第三层？是MySQL层面的权限熔断。去年Q4我们干了件别人不敢干的事：把全部应用账号的权限从SELECT ANY TABLE收缩为只读指定12张业务表，还用pt-show-grants导出脚本自动巡检——结果发现支付网关账号居然有information_schema.columns的读权限，这可是去年某竞品被拖库的入口。现在每个DB账号最多只能查3张表，INSERT操作必须走专用中间件kingshard，且每条INSERT自动生成唯一trace_id并写入审计库。说实话，这套方案让联调效率下降了18%，测试环境每次部署多花2分37秒——但值不值？上个月某垂直电商同行因SQL盲注泄露38万用户手机号，他们的DBA还在用mysql_real_escape_string。

　　最讽刺的失败案例发生在2022年6月——我们上线新商品爬虫服务，Python写的解析器把PHP后端返回的JSON里某个desc字段当字符串拼进WHERE，而该字段来自第三方ERP系统，含\\0字符。PDO预处理没触发，白名单也跳过，最后靠MySQL的max_connect_errors=3触发IP封禁才止损。这事让我确信：三层防御不是保险柜，是带报警器的防弹玻璃。

　　目前第三层的审计日志还没接入SOC平台，得等安全部下季度排期。

（编辑：均轻资讯网）

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