如何修复因第三方支付回调接口校验不严导致的SQL注入？

支付回调接口SQL注入必然存在，因验签仅保来源可信而不限制参数内容安全；必须对out_trade_no、total_amount、trade_status等字段实施白名单校验与参数化查询，解密后的resource.ciphertext也需二次过滤。

支付回调接口的SQL注入，不是“有没有”，而是“已经发生过”。验签通过 ≠ 参数安全，out_trade_no、total_amount、trade_status 这些字段一旦被直接拼进 SQL，攻击者就能用 ' OR '1'='1 之类 payload 绕过客户端直打数据库。

验签后仍被注入，是因为参数没做白名单过滤

微信或支付宝回调验签只确认“请求来自官方”，不校验参数内容。常见错误是：验签成功后，直接把 $_POST['out_trade_no'] 插入 "SELECT * FROM orders WHERE out_trade_no = '$out_trade_no'" —— 此时攻击者只要伪造合法签名（比如用泄露的 app_secret 重放+篡改），就能在 out_trade_no 里塞入恶意字符串。

• out_trade_no 必须匹配正则 /^[a-zA-Z0-9_-]{8,64}$/，禁止 '、"、;、--、/*、%、. 等字符；下划线和短横虽业务常用，但某些老系统用它们分隔字段，反而成绕过点
• total_amount 必须是严格两位小数字符串，先用 floatval() 转再用 number_format($f, 2, '.', '') 标准化，然后比对原始输入是否一致——避免传 +99.99 或 99.999 触发浮点解析漏洞
• trade_status 只允许固定枚举值：TRADE_SUCCESS、TRADE_CLOSED、WAIT_BUYER_PAY，必须用 in_array() 严格校验，禁止任何空格、换行、Unicode零宽字符

resource.ciphertext 解密后仍是危险源

微信 API v3 的 resource.ciphertext 字段解密后是 JSON 字符串，若直接 json_decode($raw, true) 后不做类型校验就入库，一样中招。比如攻击者让解密结果里 "amount" 变成 "99.99'; DROP TABLE orders;--"，后续拼 SQL 就崩了。

• 解密后必须对每个字段做二次白名单校验：金额字段强制转 float 再格式化；订单号字段再跑一遍 preg_match()
• 禁止用 extract() 或自动映射方式把解密结果直接赋给变量，必须显式取键：$data['out_trade_no'] ?? null，且每个键都单独校验
• 建议用 json_last_error() 检查解密后 JSON 是否合法，非法 JSON 直接拒绝，不进后续流程

PHP 中参数化查询必须带类型标记

用 MySQLi 做参数化不是光写 prepare() 就完事。漏掉 bind_param() 的类型标记（如 "si"），或用 query() 替代 execute()，等于没防。

• 正确写法：$stmt = $mysqli->prepare("UPDATE orders SET status = ? WHERE out_trade_no = ?"); $stmt->bind_param("ss", $status, $out_trade_no); $stmt->execute();
• 错误写法：$mysqli->query("UPDATE orders SET status = '$status' WHERE out_trade_no = '$out_trade_no'"); —— 即使前面做过过滤，也属于高危拼接
• 如果 SDK 封装了数据库操作，必须确认它内部是否真调用了 bind_param()；搜索源码里是否有 PDO::query( 或 mysql_query( 带变量插值的调用

回调幂等性与SQL注入是两件事，别混为一谈

很多人加了幂等判断（比如查订单是否存在再决定是否更新），就以为防住了注入。其实幂等只解决重复通知，不解决参数内容污染。哪怕你只执行一次 UPDATE，只要语句里有拼接，照样被注入。

• 幂等逻辑本身也要用参数化查询实现，例如 SELECT id FROM orders WHERE out_trade_no = ?
• 不要用 INSERT ... ON DUPLICATE KEY UPDATE 代替校验，因为 ON DUPLICATE KEY UPDATE 的字段值若来自未过滤参数，仍可被注入
• 最保险的做法：所有回调入口第一件事是白名单校验全部字段，失败直接 exit 或返回错误码，不进任何数据库操作分支

真正难防的不是明面上的单引号闭合，而是那些看似合规、实则绕过校验的组合：比如 ORDER-123%00（URL编码空字符）、abcu200bdef（零宽空格）、或用 Unicode 全角数字替代 ASCII 数字。白名单规则必须用 ctype_print() 或正则 /^[[:ascii:]]+$/ 限制可打印 ASCII，别信“看起来像订单号”这种模糊判断。