面向安全测试人员，提供标准化的漏洞测试用例模板，涵盖攻击步骤…

# 支付接口 SQL 注入漏洞测试用例（授权测试专用）

> ⚠️ 前提声明：本用例仅适用于自有系统或已获书面授权的测试环境，禁止对未授权目标进行测试。

一、搭建验证环境

• 靶场环境：本地部署与生产同构的测试环境（测试域名 + 隔离数据库），可复用 Docker 搭建 Web 应用 + MySQL 组合
• 脱敏数据：使用测试订单号、测试用户账号，数据库填充模拟数据（订单表、支付流水表）
• 工具准备：
• 抓包代理（如 Burp Suite Community 版 / mitmproxy）
• SQLMap（仅用于确认，建议优先手工验证）
• 数据库监控日志（观察实际执行的 SQL 语句）

二、测试用例设计

用例 1：支付订单号参数注入

• 攻击步骤：

1. 正常下单，抓取支付请求包（如 POST /api/pay，参数 order_id=xxx）

2. 将参数改为 order_id=xxx'，观察是否返回数据库报错信息

3. 依次尝试 xxx' OR '1'='1、xxx' UNION SELECT NULL-- - 等payload

4. 结合布尔/时间盲注探测：xxx' AND SLEEP(5)-- -，观察响应延迟

• 预期判定：页面报错、返回异常数据或响应明显延迟，即存在注入风险

用例 2：金额/数量字段注入

• 对 amount、coupon_code 等参数插入单引号、注释符，验证是否存在篡改支付金额的注入路径

用例 3：HTTP 头注入

• 在 Cookie、X-Forwarded-For、Referer 中插入探测 payload，部分系统会将头部写入日志查询语句

三、漏洞验证要点

• 确认数据库类型（MySQL/PG 等）以便选择对应 payload
• 记录：注入点位置、payload、响应差异截图、影响范围（能否读取/写入数据）
• 使用 SQLMap 复现时限定 --risk/--level，避免对测试库产生破坏

四、修复建议

• 参数化查询：全部支付相关 SQL 使用预编译语句（PreparedStatement/ORM 参数绑定），杜绝字符串拼接
• 输入校验：订单号、金额按白名单格式校验（如纯数字、固定长度、金额精度）
• 最小权限：支付模块数据库账号仅授予必要表的增删改查权限，禁用 FILE、多语句执行
• 错误处理：屏蔽数据库原始报错，统一返回业务错误码
• 纵深防御：接入 WAF、对支付接口增加审计日志与异常监控告警

五、回归验证

修复后重新执行全部用例 + SQLMap 扫描，确认无注入且业务功能正常，形成测试报告归档供团队复用。