快速定位SQL注入接口需聚焦三类请求：含id/query/sort的GET、拼接WHERE的POST JSON、返回数据库错误的接口；手动验证比扫描器更可靠，重点观察响应数据、延迟及状态码变化。
怎么快速定位可能被SQL注入的HTTP接口
先别急着跑扫描器，90%的漏扫失败源于没找对入口。重点盯三类请求：含 id、query、sort 参数的 GET 请求；带 WHERE 条件拼接的 POST JSON；以及任何返回数据库错误信息（比如 MySQL syntax error、ORA-00936）的接口。
实操建议：
- 用
curl -v或浏览器开发者工具抓包，过滤出所有带参数的/api/和/search类路径 - 检查响应体是否包含原始数据库报错 —— 这是注入可利用的强信号
- 注意那些看似“静态”的接口，比如
/user/profile?uid=123，后端可能正用uid拼 SQL
用 sqlmap 扫描时哪些参数最关键
sqlmap 默认行为几乎不命中真实漏洞，必须手动收紧范围、避开干扰。它不是黑盒点按钮工具，而是需要你告诉它“哪里可疑”“别乱试什么”。
实操建议：
- 强制指定测试参数：
sqlmap -u "http://x.com/api?uid=1" -p "uid"，不加-p会瞎扫所有参数 - 跳过无关技术检测：
--skip="Microsoft Access,Firebird"，只留MySQL或PostgreSQL（看目标环境） - 关掉自动 Cookie 注入：
--drop-set-cookie，否则登录态可能被覆盖导致 401 中断扫描 - 加
--level=3 --risk=2已足够，再高容易触发 WAF 封禁或服务异常
为什么有些接口明明有拼接却扫不出注入
不是工具不行，是后端用了防御性设计，而扫描器没绕过去。常见情况包括：参数被强制转整型、单引号被静默过滤、SQL 查询被封装进存储过程、或错误被统一捕获返回 200 + “系统繁忙”。
实操建议：
- 手动验证比自动扫描更可靠：把
id=1改成id=1' OR '1'='1，看响应是否多出数据 / 延迟 / 状态码变化 - 留意布尔盲注迹象：比如
id=1返回正常用户，id=1 AND 1=1也正常，但id=1 AND 1=2返回空或报错 - 如果接口用 ORM（如 Django ORM、MyBatis #{}），大概率安全 —— 但得确认没混用 ${} 或 raw SQL
扫描脚本误报高？先看这三处配置
自动化脚本（尤其是自写的 Python + requests 脚本）误报集中在请求构造和判断逻辑上。最常踩的坑是：没处理重定向、忽略 Content-Type、把 500 当作注入证据。
实操建议：
- 禁止自动跟随 302：
requests.get(url, allow_redirects=False)，否则注入 payload 可能被丢在跳转里 - 检查响应头
Content-Type是否为application/json，再解析response.json()，否则json.loads()会炸 - 不要只看状态码：有些注入让 MySQL sleep(5)，响应仍是 200，但耗时突增 —— 记录并对比
response.elapsed.total_seconds() - 避免用关键词匹配错误（如“syntax”），改用正则匹配完整错误模式：
r"MySQL.*error.*near.*\'"
真正难的不是跑出“存在注入”，而是确认它能不能走到数据库、有没有权限读写、会不会被 WAF 规则截断。手工验证那几步，比调一百个参数都管用。
