不少技术团队在安全测试时，误将 SQL 注入探测当作压测场景来处理，直接用 JMeter 配置数百个线程并发访问 /api/user?id=1。这种做法实际效果极为有限——背后的原因相当直接且现实。
一方面，sqlmap 这类专业工具之所以能精确定位注入点，核心依赖的是响应差异比对，例如错误信息是否发生变化、响应时长是否存在异常、布尔返回值的真假区别。但在高并发场景下，响应顺序完全被打乱，特征信号被淹没，难以做出准确判断。另一方面，服务端一旦发现同一 IP 高频请求相似接口，通常会触发限流或封禁策略，返回 429 甚至 503 状态码，连数据库层面的反馈都无法获取。更不用说移动端 API 普遍携带鉴权与签名机制，JMeter 很难动态维护这些头部信息，请求往往在网关层就被拦截，根本无法触及 SQL 执行层。
为什么不能直接使用 JMeter 进行“SQL 注入压力测试”
这个问题本质指向一个关键区别：SQL 注入属于安全探测范畴，而非性能压测。盲目叠加并发反而会掩盖真实的漏洞信号，甚至被风控系统误判为攻击行为。用 JMeter 执行此类任务，至少存在三大硬伤——响应特征被打乱、触发限流机制、鉴权难以动态维护。以 sqlmap 为例，它的工作机理是“单点精准试探”，每次请求都需要获取后端真实的反馈信息，并发场景下根本无法实现这一前提。
真正有效的 API 层 SQL 注入探测流程
正确的实施思路不是堆砌 QPS，而是采用「单点试探 + 上下文适配」的策略。以带 Token 的用户查询接口为例，具体流程可以拆解如下：
- 先用 curl 或 Postman 手动确认基础通路是否正常，例如 GET /api/v1/profile?uid=123 携带合法的 Authorization header，确保返回 200 状态码及预期 JSON 结构
- 将请求导出为 curl 命令格式，替换参数为注入 payload，比如 uid=123' AND SLEEP(3)--，观察响应时间是否存在明显延迟——这是时间盲注的关键判断依据
- 使用 sqlmap 的 --fresh-queries 和 --skip-static 参数启动，强制其不缓存、不跳过疑似静态参数：sqlmap -r req.txt --auth-type=Bearer --auth-cred="xxx" --level=3 --risk=2 --fresh-queries
- 如果接口走 HTTPS 且需要校验证书，需添加 --ssl-insecure；若参数位于 JSON body 中（例如 {"id": "1"}），必须用 -p id 显式指定可测参数，否则 sqlmap 默认只检测 URL 和 Cookie 部分
Android/iOS App 后端 API 的特殊处理要点
移动端 API 与 Web 端最大的差异在于「协议层封装更深、校验逻辑更复杂」，直接发送 payload 往往难以生效。实际落地时，至少需要关注以下几个关键点：
- 请求头中常见的硬性校验字段包括：X-Signature、X-Timestamp、X-Nonce，三者缺一不可。必须使用 Python 脚本重放请求并实时生成签名，不能依赖静态的 req.txt 文件
- 部分 App 对请求 body 进行了 AES 加密，尤其是支付、修改密码等敏感操作场景。此时需要先逆向获取加解密逻辑，否则 sqlmap 发送的 payload 根本无法进入后端解析环节
- URL 中的参数可能经过 Base64 编码或自定义混淆处理，例如 ?q=aGVsbG8= 解码后才是原始值 hello。必须先行解码再判断是否存在注入点，否则 ' OR '1'='1 会被当作普通字符串直接透传
- 错误信息通常被统一封装为 {"code":500,"msg":"系统繁忙"}，真实的数据库报错已被吞掉。此时只能依赖时间盲注（SLEEP）或布尔盲注（AND 1=1 vs AND 1=2 观察响应体长度或状态码的细微差异）来进行判断
最容易被忽视的一点是：许多团队使用 sqlmap --batch 批量扫描大量 URL，却没有逐一确认每个请求是否真实到达了目标数据库。中间经过的 WAF、API 网关、业务网关可能已经静默拦截或重写了参数。务必通过后端日志或数据库审计日志反向验证 payload 是否真正进入了 executeQuery()——这才是判断测试是否有效的唯一可靠标准。
