web api的sql注入验证不能只看http状态码或错误页面，而需重点观察响应体结构变化、字段值差异、响应时间抖动及header异常，尤其在json api中静默处理错误时，细微的content-length变动、data字段null/对象切换、set-cookie重置等才是关键注入信号。
直接判断：Web API的SQL注入验证不能只看HTTP状态码或错误页面——它更依赖响应体结构、字段值变化、响应时间抖动和Header差异，尤其是当API返回JSON且错误被静默吞掉时。
Repeater里怎么确认API参数存在注入点
别指望看到MySQL报错，API通常把异常转成500或统一{"error":"internal"}。关键看三处细微变化：
- 修改参数加单引号：
id=1'，对比原始请求的Content-Length是否突变（哪怕只差1字节） - 尝试闭合：
id=1'-- -或id=1")，观察响应中data字段是否从null变回对象，或success字段从false切回true - 检查
Set-Cookie或X-RateLimit-Remaining这类Header是否随Payload异常而重置——说明后端执行路径已改变
JSON body里的SQL注入怎么测
API大量用POST /api/users带JSON body，Content-Type: application/json，这时普通URL参数测试完全失效：
- 在Repeater中右键→
Change request method为POST，手动把body改成JSON格式，比如{"id": "1' AND 1=1-- -"} - 注意双引号必须转义：
{"id": "1' AND \"a\"=\"a"-- -"}，否则Burp会解析失败 - 若后端用ORM但拼接了raw SQL（如Node.js的
knex.raw()），id字段可能被当字符串处理，此时要试"1' || '1'='1"（SQLite）或"1' OR '1'='1"（MySQL） - 别漏
Cookie或Authorization头里的token字段——有些API把user_id藏在JWT payload里，解码后改sub字段再重签，也能触发注入
Intruder跑布尔盲注时怎么避免误判
API响应常含动态时间戳、随机request_id、浮动的updated_at字段，靠肉眼比长度或内容哈希极易翻车：
- 进
Intruder → Options → Grep-Match，填精准定位字段，比如"count":0vs"count":1，或"valid":truevs"valid":false - 勾选
Redecode responses before matching，防止URL编码干扰关键词匹配 - 用
Comparer模块加载两个响应，右键→Compare side by side，关掉“Show whitespace differences”，专注比data数组长度或特定key的value值 - 时间盲注慎用
SLEEP()——API网关常有超时熔断（如3秒截断），改用BENCHMARK(1000000,MD5(1))（MySQL）或pg_sleep(0.5)（PostgreSQL）更稳
xia_sql插件在API场景下必须调哪些参数
默认配置对HTML页面友好，但JSON API需要手动干预：
- 必须先在Repeater发一次原始请求，右键→
Set as baseline，否则插件所有维度比对都失准 - 关闭
Response Body Hash检测，启用JSON Path Match：填$.data.length或$.user.email，让插件只盯目标字段值变化 - 若API用GraphQL，Payload需走
query字段，插件要勾选Treat query parameter as GraphQL operation（v2.1+） - CDN缓存导致响应时间不可靠？直接关掉
Time-based detection，把权重全压到Status Code和JSON Path Match上
最易被忽略的是API的“静默降级”行为：比如id=1' OR 1=1不报错也不返回数据，但id=1' UNION SELECT 1,2,3却让整个data字段变成null——这种非报错型逻辑破坏，才是真实环境中最难捕获的注入信号。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
